Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

スタートアップ企業で始めるAWSセキュリティ対策 ~内部統制の観点から~ / AWS Secu...

Yuji Oshima
November 21, 2022

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

「Security-JAWS【第27回】」で発表した資料です。
https://s-jaws.doorkeeper.jp/events/146327

「クラウドセキュリティエンジニアブログ」
Security-JAWS【第27回】で「スタートアップ企業で始めるAWSセキュリティ対策 ~内部統制の観点から~」というタイトルで登壇しました
https://devblog.nuligen.com/entry/20221205/1670215672

Yuji Oshima

November 21, 2022
Tweet

More Decks by Yuji Oshima

Other Decks in Technology

Transcript

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

    2022 APN ALL AWS Certifications Engineers ◼ 経歴 • デジタルフォレンジック、マルウェア解析、スレットインテリジェンス • SOC、基盤運用、インシデントレスポンス • ニューリジェンの創業メンバーとして サービス開発/基盤構築運用/研究開発に従事 Azure×6, GCP×4 CISSP, GIAC×3, ISACA×2 yuj1osm 2
  2. 内部統制の重要性 ◼ 内部統制 • 組織の業務の適正を確保するための体制を構築していくシステム 5 目的 1. 業務の有効性・効率性 2.

    財務報告の信頼性 3. 法令順守 4. 資産の保全 基本要素 1. 統制環境 2. リスクの評価と対応 3. 統制活動 4. 情報と伝達 5. モニタリング 6. ITへの対応 IT統制に着目 ◼ ITにおける内部統制の重要性 • サイバー攻撃が巧妙化する一方で、内部不正やリスクコントロールの不備による情報漏洩も後を絶たない • クラウド化が加速する現在、不特定多数のアクセスにさらされるクラウド利用における統制はさらに重要 • 健全なシステム運用、アクセス統制や権限管理が必要不可欠
  3. スタートアップこそ内部統制に気を使うべき理由 ◼ スタートアップの爆速的な速さ • とにかくリリース頻度が早く、セキュリティが二の次 • ルールがない中で、どんどんプロダクトが増加 • プロダクトの追加や検証で、急にアカウント追加が必要 ◼

    急に求められるセキュリティの水準向上 • セキュリティ監査や認証取得 • ステークホルダーからの要求 6 遅かれ早かれ内部統制への対策に時間をかける必要性が出てくる 初期段階でしっかりセキュリティ対策をし、統制の取れた運用をするべき
  4. シングルアカウント ◼ シングルアカウント構成の課題 • セキュリティやガバナンスの確保が困難 • 権限管理が困難 • タグベースで権限管理も可能だが複雑化 •

    課金の分離が困難 • 各アカウントのコスト状況の把握が困難 • コスト配分タグで管理も可能だが複雑化 • 運用が困難 • オペミスによる本番ワークロード削除のリスク • サービスクォータ値に引っかかる AWS Cloud 8 VPC(開発) VPC(ステージング) VPC(本番) VPC単位で環境を分ける例 様々な環境が混在
  5. マルチアカウント ◼ マルチアカウント構成のメリット • セキュリティやガバナンスの向上 • アカウント毎に権限を分離しやすい • 課金の分離 •

    アカウント毎の課金状況を把握しやすい • 運用の効率化 • 変更の影響を最小限にできる ◼ アカウント分離の切り口 • 開発環境 • ステージング環境 • 本番環境 • 請求管理環境 • ユーザ管理環境 • ログアーカイブ環境 • 監査環境 AWS Cloud(開発) AWS Cloud(ステージング) AWS Cloud(本番) 9 アカウント単位で環境を分ける例
  6. マルチアカウントの構成例 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情報を集約
  7. マルチアカウント構成を手軽に実現する方法 ◼ 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
  8. 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
  9. Change Managerでアクセス管理 ◼ Change Managerとは? • AWS Systems Managerの1機能であり、アプリやインフラの変更管理を提供 •

    承認フローを組める ◼ どのように変更管理と本番アクセス統制をするか • 本番アクセス用グループを新たに作成 • このグループからのみ本番環境の作業ロールにスイッチ可能 • Change Managerの承認でこのグループに追加 • グループ追加とともにTTLタグをつける ※グループの参加期限を示したタグ 16
  10. 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
  11. 請求情報の閲覧禁止 ◼ 請求情報は必要以上に閲覧させない • 外部の協力会社などに金銭事情を把握される • ホワイトリスト方式だと、うっかり「ReadOnlyAccess」を 与えると閲覧できてしまうため、明示的に拒否することを推奨 26 {

    "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "aws-portal:*", "Resource": "*" } ] } IAMユーザはデフォルトで請求情報にアクセス不可 アクティブ化+Billing閲覧権限が必要 ※Organizationから作成されたメンバーアカウントは 本設定がデフォルトでONになっているので注意 IAMユーザが所属しているグループと、 スイッチ先のロールにaws-portalを拒否 するポリシーを付与
  12. S3オブジェクトのダウンロード禁止 ◼ 不要なダウンロードはさせない • S3は個人情報などの機微な情報を扱うケースが多い • 「ReadOnlyAccess」でもオブジェクトダウンロードが可能なため明示的に拒否することを推奨 27 { "Version":

    "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:GetObject", "Resource": "*" } ] } S3:GetObjectを明示的に拒否 明示的な拒否ポリシーが付与されている状態で オブジェクトダウンロードしようとすると失敗する
  13. ネットワークの作成禁止 ◼ 不要ネットワークを作成させない • 管理者が把握していない出口経路の作成を禁止する • もちろん削除させることも禁止する方が望ましいが、 作成拒否の方が優先度は高いと考える • あらかじめ決まったネットワーク構成を用意してあげるとよい

    29 { "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:CreateVpc*", "ec2:ModifyVpc*", "ec2:AttachInternetGateway", "ec2:CreateInternetGateway", "ec2:CreateNatGateway" ], "Resource": "*", "Effect": "Deny" } ] } VPC/IGW/NATGWの作成を 明示的に拒否
  14. 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を削除すればよい
  15. アカウント毎の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 指定 ステージング環境と本番環境は、 開発環境で作成したテンプレートをデプロイする