スタートアップ企業で始めるAWSセキュリティ対策 ～内部統制の観点から～ / AWS Security and Internal Audit at a Startup

Transcript

1. スタートアップ企業で始めるAWSセキュリティ対策 ～内部統制の観点から～ 大島 悠司 Security-JAWS【第27回】 勉強会

2. 自己紹介 ◼ 大島 悠司（おおしま ゆうじ） • ニューリジェンセキュリティ株式会社 • クラウドセキュリティアーキテクト/基盤リーダー •

   2022 APN ALL AWS Certifications Engineers ◼ 経歴 • デジタルフォレンジック、マルウェア解析、スレットインテリジェンス • SOC、基盤運用、インシデントレスポンス • ニューリジェンの創業メンバーとして サービス開発/基盤構築運用/研究開発に従事 Azure×6, GCP×4 CISSP, GIAC×3, ISACA×2 yuj1osm 2

3. アジェンダ ◼ スタートアップこそ内部統制に気を使うべき理由 ◼ アカウント分離とIAM設計 ◼ Change Managerによる本番アクセス統制 ◼ 統制上考慮すべき権限

   3

4. スタートアップこそ内部統制に気を使うべき理由 4

5. 内部統制の重要性 ◼ 内部統制 • 組織の業務の適正を確保するための体制を構築していくシステム 5 目的 1. 業務の有効性・効率性 2.

   財務報告の信頼性 3. 法令順守 4. 資産の保全 基本要素 1. 統制環境 2. リスクの評価と対応 3. 統制活動 4. 情報と伝達 5. モニタリング 6. ITへの対応 IT統制に着目 ◼ ITにおける内部統制の重要性 • サイバー攻撃が巧妙化する一方で、内部不正やリスクコントロールの不備による情報漏洩も後を絶たない • クラウド化が加速する現在、不特定多数のアクセスにさらされるクラウド利用における統制はさらに重要 • 健全なシステム運用、アクセス統制や権限管理が必要不可欠

6. スタートアップこそ内部統制に気を使うべき理由 ◼ スタートアップの爆速的な速さ • とにかくリリース頻度が早く、セキュリティが二の次 • ルールがない中で、どんどんプロダクトが増加 • プロダクトの追加や検証で、急にアカウント追加が必要 ◼

   急に求められるセキュリティの水準向上 • セキュリティ監査や認証取得 • ステークホルダーからの要求 6 遅かれ早かれ内部統制への対策に時間をかける必要性が出てくる 初期段階でしっかりセキュリティ対策をし、統制の取れた運用をするべき

7. アカウント分離とIAM設計 7

8. シングルアカウント ◼ シングルアカウント構成の課題 • セキュリティやガバナンスの確保が困難 • 権限管理が困難 • タグベースで権限管理も可能だが複雑化 •

   課金の分離が困難 • 各アカウントのコスト状況の把握が困難 • コスト配分タグで管理も可能だが複雑化 • 運用が困難 • オペミスによる本番ワークロード削除のリスク • サービスクォータ値に引っかかる AWS Cloud 8 VPC（開発） VPC（ステージング） VPC（本番） VPC単位で環境を分ける例 様々な環境が混在

9. マルチアカウント ◼ マルチアカウント構成のメリット • セキュリティやガバナンスの向上 • アカウント毎に権限を分離しやすい • 課金の分離 •

   アカウント毎の課金状況を把握しやすい • 運用の効率化 • 変更の影響を最小限にできる ◼ アカウント分離の切り口 • 開発環境 • ステージング環境 • 本番環境 • 請求管理環境 • ユーザ管理環境 • ログアーカイブ環境 • 監査環境 AWS Cloud（開発） AWS Cloud（ステージング） AWS Cloud（本番） 9 アカウント単位で環境を分ける例

10. マルチアカウントの構成例 AWS Cloud（開発） AWS Cloud（ステージング） AWS Cloud（本番） 10 AWS Cloud（請求管理）

    AWS Cloud（ログアーカイブ） AWS Cloud（監査） AWS Cloud（ユーザ管理） Amazon S3 AWS CloudTrail AWS Config AWS Security Hub IAM Access Analyzer Amazon GuardDuty AWS CloudTrail AWS Config User1 AWS CloudTrail AWS Config AWS CloudTrail AWS Config AWS CloudTrail AWS Config AWS CloudTrail AWS Config AWS CloudTrail AWS Config ユーザ管理アカウント経由で 他アカウントへアクセス TrailとConfigログを集約 TrailとConfig情報を集約

11. マルチアカウント構成を手軽に実現する方法 ◼ AWS Organizations • 複数アカウントの一元管理 • アカウント管理の自動化 • 一括請求

    ◼ AWS Control Tower • 以下を含めたセキュリティサービスの一括設定 • AWS Organizations • AWS Single Sign-On • AWS Service Catalog • AWS Config • AWS CloudTrail 11 AWS Organizations Management OU OU Permissions AWS Control Tower AWS Single Sign-On AWS Cloud（管理） Log Archive Audit Core OU Custom OU AWS Organizations

12. Jumpアカウント方式 ◼ Jumpアカウントを用意し、IAMユーザを集約 ◼ 利用者はJumpアカウントにログインし、各アカウントへスイッチロール ◼ 各アカウントの権限はスイッチ先ロールに付与 AWS Cloud（開発） AWS

    Cloud（ステージング） AWS Cloud（本番） User1 User2 User3 Jumpアカウントへ ログイン AWS Cloud（Jump） User1 User2 User3 Role Permissions Role Permissions Role Permissions AWS STS 各アカウントへ スイッチロール Permissions 12

13. IAM設計のコツ ◼ 役割ごとにグループを分ける ◼ グループに対して、スイッチできるアカウントとロールを固定 • リーダーグループは高権限のロール、メンバーグループは低権限のロールにスイッチ • 読み取り専用権限のロールもあると安心 13

14. 本番環境へのアクセス統制どうする？ ◼ 変更管理 • 誰が、いつ、変更作業のために本番環境にログインしたか追える？ ◼ 本番アクセス統制 • 本番環境にいつでもログインできるようになっていないか？ ここをどうやって

    管理・統制する？ 14

15. Change Managerによる本番アクセス統制 15

16. Change Managerでアクセス管理 ◼ Change Managerとは？ • AWS Systems Managerの1機能であり、アプリやインフラの変更管理を提供 •

    承認フローを組める ◼ どのように変更管理と本番アクセス統制をするか • 本番アクセス用グループを新たに作成 • このグループからのみ本番環境の作業ロールにスイッチ可能 • Change Managerの承認でこのグループに追加 • グループ追加とともにTTLタグをつける ※グループの参加期限を示したタグ 16

17. Change Managerでアクセス管理 全体図 ◼ 詳細な実装方法や説明は割愛、関連資料は後述 17

18. 動作確認 ◼ 承認フローを得て本番環境にアクセスできるか確認 18

19. 事前アクセス確認 ◼ ProdMemberWorkGroupに所属していないのでスイッチ不可 19

20. リクエスト作成 ◼ 本番作業をするユーザがリクエストを作成する リクエストを作成する パラメータを入力 ・IAMユーザ名 ・グループ名（本番作業グループ） ・TTL（作業終了日時） 承認依頼 20

21. リクエスト承認 ◼ 承認者が承認する タスクが実行される 承認者がコメント付きで承認 タイムラインでタスクのステータスや 承認者が見れる 21

22. 本番環境へスイッチロール ◼ 再度、本番環境へスイッチロールしてみる リクエスト作成で入力した グループへの追加と、 TTLタグが付いている 今度は本番環境へスイッチロールできた 22

23. 全体図を振り返り 23 ◼ ユーザの手間を最小限に、セキュアな本番アクセス統制を実現

24. Change Managerによる本番アクセス統制 参考資料 ◼ 「JAWS-UG情シス支部 第28回」で発表した資料 https://speakerdeck.com/yuj1osm/access-controle-with-aws-systems-manager- change-manager ◼ 「クラウドセキュリティエンジニアブログ」

    詳細な実装手順やポイントを掲載 • Change Managerによる変更管理と本番アクセス統制 ①動機づけ編 https://devblog.nuligen.com/entry/20221205/1670215415 • Change Managerによる変更管理と本番アクセス統制 ②マルチアカウント&IAM設計編 https://devblog.nuligen.com/entry/20221205/1670215444 • Change Managerによる変更管理と本番アクセス統制 ③Session Managerログイン&ロギング編 https://devblog.nuligen.com/entry/20221205/1670215458 • Change Managerによる変更管理と本番アクセス統制 ④Change Managerセットアップ編 https://devblog.nuligen.com/entry/20221205/1670215474 • Change Managerによる変更管理と本番アクセス統制 ⑤テンプレート作成編 https://devblog.nuligen.com/entry/20221205/1670215486 • Change Managerによる変更管理と本番アクセス統制 ⑥動作確認編 https://devblog.nuligen.com/entry/20221205/1670215510 • Change Managerによる変更管理と本番アクセス統制 ⑦まとめ https://devblog.nuligen.com/entry/20221205/1670215524 24

25. 統制上考慮すべき権限 25

26. 請求情報の閲覧禁止 ◼ 請求情報は必要以上に閲覧させない • 外部の協力会社などに金銭事情を把握される • ホワイトリスト方式だと、うっかり「ReadOnlyAccess」を 与えると閲覧できてしまうため、明示的に拒否することを推奨 26 {

    "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "aws-portal:*", "Resource": "*" } ] } IAMユーザはデフォルトで請求情報にアクセス不可 アクティブ化+Billing閲覧権限が必要 ※Organizationから作成されたメンバーアカウントは 本設定がデフォルトでONになっているので注意 IAMユーザが所属しているグループと、 スイッチ先のロールにaws-portalを拒否 するポリシーを付与

27. S3オブジェクトのダウンロード禁止 ◼ 不要なダウンロードはさせない • S3は個人情報などの機微な情報を扱うケースが多い • 「ReadOnlyAccess」でもオブジェクトダウンロードが可能なため明示的に拒否することを推奨 27 { "Version":

    "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:GetObject", "Resource": "*" } ] } S3:GetObjectを明示的に拒否 明示的な拒否ポリシーが付与されている状態で オブジェクトダウンロードしようとすると失敗する

28. S3オブジェクトの削除禁止 ◼ 不要な削除はさせない • サービスで必要なデータやTrail/Configのログデータ • 明示的に拒否することを推奨 • オブジェクトロック機能を使うことも検討 28

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:Delete*", "Resource": "*" } ] } S3:Deleteを明示的に拒否

29. ネットワークの作成禁止 ◼ 不要ネットワークを作成させない • 管理者が把握していない出口経路の作成を禁止する • もちろん削除させることも禁止する方が望ましいが、 作成拒否の方が優先度は高いと考える • あらかじめ決まったネットワーク構成を用意してあげるとよい

    29 { "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:CreateVpc*", "ec2:ModifyVpc*", "ec2:AttachInternetGateway", "ec2:CreateInternetGateway", "ec2:CreateNatGateway" ], "Resource": "*", "Effect": "Deny" } ] } VPC/IGW/NATGWの作成を 明示的に拒否

30. IAM操作の禁止 ◼ IAM操作をさせない • 必要以上に高権限のポリシー作成、既存ポリシーの削除を禁止する • IAM操作を許可しない「PowerUserAccess」を使う手もあり • IAM操作をCloudFormation経由のみ許可する運用も検討 30

    { "Version": "2012-10-17", "Statement": [ { "Action": [ "iam:Get*", "iam:List*", "iam:PassRole" ], "Resource": "*", "Effect": "Allow" } ] } 「PowerUserAccess」のみだと IAM権限が不足するため、 これらも許可する AWS CloudFormation { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] } CloudFormation-Role 指定 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } 許可 信頼関係 CloudFormation用のロールを用意し、 CloudFormation利用時に指定させる 運用にする 証跡としても活用でき、運用に不都合 が生じたらStackを削除すればよい

31. アカウント毎のIAM操作権限と運用例 ◼ スタートアップにおいてはスピードが求められるため、開発を阻害し過ぎないことも重要 31 AWS Cloud（開発） AWS Cloud（ステージング） AWS Cloud（本番）

    { "Version": "2012-10-17", "Statement": [ { "Action": [ "iam:Get*", "iam:List*", "iam:PassRole", "iam:CreatePolicy", "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion", "iam:CreateRole", "iam:DeleteRole", "iam:UpdateRole*", "iam:PutRolePolicy", "iam:AttachRolePolicy", "iam:DetachRolePolicy", "iam:DeleteRolePolicy", "iam:CreateInstanceProfile", "iam:AddRoleToInstanceProfile", "iam:UpdateAssumeRolePolicy" ], "Resource": "*", "Effect": "Allow" } ] } PowerUserAccess + { "Version": "2012-10-17", "Statement": [ { "Action": [ "iam:Get*", "iam:List*", "iam:PassRole" ], "Resource": "*", "Effect": "Allow" } ] } { "Version": "2012-10-17", "Statement": [ { "Action": [ "iam:Get*", "iam:List*", "iam:PassRole" ], "Resource": "*", "Effect": "Allow" } ] } 開発環境は手作業のIAM操作をある程度許容 開発者はここでCloudFormationテンプレートを作成 過剰な権限作成に気付ける仕組みは用意しておく AWS CloudFormation 前述のCloudFormation-Role 指定 ステージング環境と本番環境は、 開発環境で作成したテンプレートをデプロイする

32. まとめ ◼ スタートアップこそ、早期に内部統制の視点でセキュリティ対策をする必要性 ◼ マルチアカウント設計をし、セキュリティ機能やログ保存は別アカウントに集約 ◼ IAM設計は、役割ごとに権限を整理し、本番環境へのアクセス権限が過剰でないかも確認 ◼ Change Managerを使うことで変更管理とアクセス統制の仕組みを実現

    ◼ 各アカウントでのユーザの権限が過剰でないか確認 ◼ 開発効率を落とさないために、使いやすさとセキュリティのバランスを考えることが重要 32