© Chatwork ガードレール運用 2023年8月31日　SRE部　佐々木真也 Chatwork株式会社 JAWS-UG 大阪 「AWS のセキュリティサービス＆ソリューション座談会（仮）」

自己紹介 2 ● 名前 ○ 佐々木真也 ● 所属 ○ Chatwork株式会社 ■ 2020年6月〜 ■ SRE部 マネージャー ● Twitter ○ @taishin ● 趣味 ○ サッカー観戦

会社概要 3 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 グループ従業員数 411名（2023年6月末日時点） 所在地 東京、大阪 設立 2004年11月11日

事業概要 4 4 *1 Chatworkセグメント以外の事業として、ESET社提供のセキュリティ対策ソフトウェア「ESET」の代理販売事業を展開。安定的な収益貢献となっている *2 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスをChatwork株式会社にて選定 *3 2023年6月末時点 ● 国内最大級のビジネスチャット「Chatwork」を中心に、複数の周辺サービスを展開*1 ● ビジネスチャットのパイオニアであり国内利用者数No.1*2、導入社数は41.0万社*3を突破 ● 電話やメールから効率的なチャットへ、ビジネスコミュニケーションの変化を加速させプラットフォーム化を目指す

ガードレール？ Chatworkのガードレール運用 まとめ 2 3 AGENDA アジェンダ 1

ガードレール？

クラウドにおけるガードレールとは？ 7 ● クラウド環境でセキュリティなどの統制を実現する方法、考え方 ● 利用者がセキュリティ上問題のある操作をしないよう検知・防止 する仕組み

従来のセキュリティ対策 8 ● ゲート ○ 特定のアクションや操作を実行する前に、認証や承認を必要とする 仕組み

ガードレール利用の背景 9 ● 利用者の増加 ● 組織としてガバナンス強化 ● マルチアカウント管理 ● 開発スピード

ガードレールの種類 10 ● 検知 ○ リスクがある構成や操作を検知し、止めるので はなく通知する ■ ex) パブリックアクセス可能なS3バケットを作成した後、通知 する ● 予防 ○ あらかじめしてはいけない操作を定義し、禁止 する ■ ex) パブリックアクセス可能なS3バケットを作成しようとした ときに、操作をブロックする ※ 修正を1つの種類として取り扱っているドキュメントもあります。

ガードレールといえば・・・ 11 ● AWS Control Tower ○ 複数のAWSサービスを組み合わせてマルチアカウントの統制を行う

Control Tower の機能 12 ● ランディングゾーン ○ セキュリティとコンプライアンスのベストプラクティスに基づく マルチアカウント管理 ● コントロール ○ AWS 環境全体に継続的なガバナンスを提供する高レベルのルール ○ ガードレールとも呼ばれる ● Account Factory ○ 新規アカウントのテンプレート ● ダッシュボード

Control Tower の必須コントロールの例 13 ● AWS Control Tower がログアーカイブに作成した Simple Storage Service (Amazon S3) バ ケットのログ設定の変更を許可しない ● AWS Control Tower によって設定された Amazon CloudWatch Logs ロググループへの変更 を不許可にする ● AWS Control Tower が作成した AWS Config 集約認証の削除を許可しない ● AWS Control Tower によって設定された Amazon CloudWatch への変更を不許可にする ● AWS Control Tower が作成した リソースのタグの変更を許可しない … ● 利用可能なすべてのリージョンで CloudTrail を有効にする ● CloudTrail への設定変更を不許可にする ● セキュリティ組織単位の共有アカウントで AWS CloudTrail または CloudTrail Lake が有効 になっているかどうかを検出する … ● 使用可能なすべてのリージョンで AWS Config を有効にする ● AWS Config への設定変更を許可しない https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/mandatory-controls.html

検知ガードレールを実現するAWSのサービス 14 ● AWS Config Rules ● Security Hub

AWS Config Rules 15 ● AWS リソースの設定内容を評価 ○ AWS Config マネージドルール ■ 事前定義されたカスタマイズ可能なルール ● https://docs.aws.amazon.com/config/latest/developerguide/managed- rules-by-aws-config.html ○ AWS Config カスタムルール ■ Lambda ■ CloudFormation Guard ■ RDK

AWS Security Hub 16 ● セキュリティのベストプラクティスのチェック ○ CIS AWS Foundations Benchmark、AWS 基礎セキュリティのベストプラクティス 等 ● 他のサービスのセキュリティアラートを集約

予防ガードレールを実現するAWSのサービス 17 ● サービスコントロールポリシー (SCP) ● IAM

サービスコントロールポリシー (SCP) 18 ● AWS Organizations における権限設定 ○ Organizations内のOU（Organizational Unit) や、AWSアカ ウントに対する権限を設定

Chatworkの予防ガードレール運用

Security Hub運用 20 Security Hub SNS Event Bridge

Security Hub運用 21 ● カスタムアクションの利用 ○ Jiraチケット作成や、通知に必要な情報は、検知するサービスごとに異なる ○ EventBridgeの入力トランスフォーマーで必要な情報を抽出

Security Hub運用 22 ● Security Hub Automation Rules による検出結果の更新 ○ 下記の情報等を自動更新 ■ ステータス変更 ■ アカウントの選定 ■ findingsごとに除外の選定 https://aws.amazon.com/jp/about-aws/whats-new/2023/06/aws-security-hub-automation-rules/

課題 23 ● システム担当者への通知 ○ 同じアカウント内に複数のシステムが構築されているので、タグをチェックする 等でシステムごとに通知先を分けたいが、タグの対応がないのでアカウントレベ ルでしか通知先を分けれない ● Custom Action の手動実行 ○ 現状の仕様だと過去に実行したものを再度実行してしまい、チケット、通知が重 複してしまうため ● Jiraチケットとの連携 ○ Security Hubでステータスを変更してもJiraでは変わらない ■ Atlassian Jira Service Management との双方向統合を検証中 ● https://aws.amazon.com/jp/about-aws/whats-new/2021/05/aws-security-hub -supports-bidirectional-integration-with-atlassian-jira-service-management/

Chatworkの検知ガードレール運用

SCPの運用 25 ○ 絶対に使わないものを拒否 ○ 最小限にしておく ■ 変更はOrganizationsに対する権限がないとできない ■ アカウント側で拒否されたときに問題がよく分からない { "Effect": "Deny", "Action": "*", "Resource": "*", "StringNotEquals": { "aws:RequestedRegion": [ "ap-northeast-1", "us-east-1", "us-east-2", "us-west-1", ... }, { "Effect": "Deny", "Action": [ "workspaces:*", "workspaces-web:*", "robomaker:*", "mediatailor:*", ... ● 例 ○ 不要なリージョンに対する操作 ○ 不要なサービスに対する操作 ○ 絶対に削除してはいけないS3バケット/オブ ジェクトの削除の拒否

予防ガードレールの運用 26 ● ガードレールをつくりたいポイント ○ Organizationレベル Organizationレベルのガードレール ● 組織管理者で設定 ● SCPを利用

予防ガードレールの運用 27 ● ガードレールをつくりたいポイント ○ Organizationレベル ○ アカウントレベル Organizationレベルのガードレール ● 組織管理者で設定 ● SCPを利用 アカウントレベルのガードレール ● アカウント管理者で設定

予防ガードレールの運用 28 ● ガードレールをつくりたいポイント ○ Organizationレベル ○ アカウントレベル ○ EKSクラスタレベル Organizationレベルのガードレール ● 組織管理者で設定 ● SCPを利用 アカウントレベルのガードレール ● アカウント管理者で設定 EKSクラスタレベルのガードレール ● クラスタ管理者で設定

アカウントレベルのガードレール 29 ● リソース作成時にブロック ○ terraformでのCI/CD作成時にブロック ■ Atlantis + OpenPolicyAgent/Conftest

Atlantis + Conftest 30 ● 権限設定次第ですが、エラーを承 認してapplyすることも可能 ● Terraformのplan結果をOPAの仕組みで検査 ● ポリシー違反であればapply不可 ○ エラーを承認してapplyすることも可能 ■ (緩さも必要かも・・・)

参考：tfsec 31 ● Terraformのコードをセキュリティのベストプラクティス に基づいてスキャンしてくれる ○ Github ActionsでCI/CDに組み込むことも可能 ○ ユーザー側で除外も可能 ■ (緩さも必要かも・・・) https://github.com/aquasecurity/tfsec

参考：AWS Config ルール プロアクティブモード ？ 32 ● 期待していたものと違った・・・

EKSクラスタレベルのガードレール 33 ● EKSクラスタ内でGatekeeper + OpenPolicyAgent ○ コンテナイメージのタグのチェック ○ Adminロールのチェック ○ external-dnsホスト名のチェック https://aws-quickstart.github.io/cdk-eks-blueprints/addons/opa-gatekeeper/ https://archive.eksworkshop.com/intermediate/310_opa_gatekeeper/

詳細はこちらにも・・・ 34 ● https://speakerdeck.com/saramune/gabanansuxiang-shang-wei-yuan-hui-with-opa

まとめ

まとめ 36 ● ガードレールには検知と予防がある ● 検知ガードレールは通知運用が難しい ● 予防ガードレールはレイヤに応じてサービスを選択

働くをもっと楽しく、創造的に