DevelopersIO 2022で登壇した資料です。 https://classmethod.jp/m/developers-io/
詳細な解説はブログをご参照ください。 https://dev.classmethod.jp/articles/devio-2022-how2make-strongest-aws-secure-accounts/
[⽬指せ上級者]最強にセキュアなAWSアカウントの作り⽅2022/07/26AWS事業本部 コンサルティング部⾅⽥佳祐ハッシュタグ #devio2022
View Slide
みなさんAWSのセキュリティ確保してますか︖(挨拶
3⾃⼰紹介⾅⽥佳祐(うすだけいすけ)・クラスメソッド株式会社AWS事業本部シニアソリューションアーキテクトセキュリティチームリーダーAWS公認インストラクター2021 APN Ambassador・CISSP・Security-JAWS運営・好きなサービス:Amazon DetectiveみんなのAWS(技術評論社)
4セッションテーマ⾃分たちの最強のAWS環境を作ろう
5セッション対象者• プロジェクトのAWSアカウント管理者• 組織のAWSアカウント管理者• セキュリティ担当者• セキュリティ責任者• AWS利⽤者
6アジェンダ0. ⻑い前置き1. セキュアなアカウント単体の原理2. ベンディングマシンとアカウント運⽤3. 最強にセキュアな運⽤
70. ⻑い前置き
8セッション概要• 中級者から上級者を⽬指すセッション• 最強のAWSアカウントを作っていく• どうやって︖
9最強にセキュアなAWSアカウントとは︖AWSには最初から利⽤すべきサービスが様々ある• CloudTrail• Config• GuardDuty• Security Hub• IAM Access Analyzer• Detective• などなど
10最強にセキュアなAWSアカウントとは︖これらが設定されていればセキュア︖
11最強にセキュアなAWSアカウントとは︖後から増えるAWSリソースはセキュアかわからないセキュリティグループは社内IPのみに制限されている︖RDSのスナップショットを公開していない︖EC2のAMIは信頼できる︖ALBのログは取得している︖Lambdaは外部からアクセス・実⾏できない︖API GatewayはX-Rayを適⽤している︖SageMakerは直接インターネットにアクセスできない︖CloudFrontはOAIを利⽤している︖
12つまり…最強にセキュアなAWSアカウントを作る=継続的にセキュアな状態を組織で維持する仕組みを作る=セキュリティ運⽤設計
13上級者を⽬指すなら組織全体を巻き込んですべてのAWS利⽤者がセキュリティを意識してセキュアな環境が⾃動的に維持される⽂化を作るべし(上級者は巻き込むことが仕事)
14このセッションでは• 最初にセキュリティを確保する仕組みを説明し• 次にそれを展開する⽅法を説明し• 最後に運⽤実装例を⽰す
15アジェンダ(再掲)0. ⻑い前置き1. セキュアなアカウント単体の原理2. ベンディングマシンとアカウント運⽤3. 最強にセキュアな運⽤
16合わせて読みたいセキュリティ対策はだいたいここに全部あるhttps://dev.classmethod.jp/articles/aws-security-all-in-one-2021/
171. セキュアなアカウント単体の原理
18いろんな対策があるけどどこからやっていけばいい︖
19AWS Security Hubはベースラインの参考になる直感的なスコア表⽰で達成度がわかりやすい
20AWS Security Hubはベースラインの参考になる• AWS Security Hubの「AWS基礎セキュリティベストプラクティス」によるセキュリティチェックは各種AWSサービスの危険な設定を発⾒し、ベストプラクティスに基づいた設定へ導いてくれるSSHポートが開放されていないかS3バケットが公開されていないかルートユーザーのアクセスキーを利用していないかALBのログが保存されているかCloudTrailで証跡を保存しているかEC2にパブリックIPが付与されていないかGuardDutyを有効化しているかLambda関数が公開されていないか
21セキュアアカウントが参考になりますセキュアなAWS設定と実運⽤の例デフォルトでセキュリティを強化したAWSアカウント発⾏も無償でしてます(宣伝)https://dev.classmethod.jp/articles/aws-security-operation-bestpractice-on-secure-account/
22合わせて読みたいセキュアアカウントの仕組みの説明とコツはこちらにありますhttps://dev.classmethod.jp/articles/220408-training-webinar-aws-security-management/
23こんな感じの設定が⼊っているといい
24各種設定の概要とコツを解説
25AWS上の証跡管理• CloudTrail• すべての管理イベント• Config• すべてのリソース記録• グローバルリソース記録• S3• ログのライフサイクル3年• SSE-KMSによる暗号化
26AWS上の証跡管理のコツ• Configのグローバルリソース記録は東京リージョンのみ有効化する(全リージョンで⼊れると重複して記録されるため)• ライフサイクル3年は⾃社のログ保持基準に照らし合わせて調整する• WORMを設定すると強⼒
27デフォルトのS3公開防⽌• AWSアカウントレベルのブロックパブリックアクセスを有効化• ブロックパブリックアクセスはアカウントレベルとバケットレベルがある• アカウントレベルを設定するとAWSアカウント全体で適用される• うっかり公開してしまうことを防げる
28デフォルトのS3公開防⽌のコツ• S3に公開⽤のHTML / CSS /JavaScriptなどのWeb⽤や画像/動画などの静的コンテンツを配置する場合でもCloudFrontのOriginAccess Identity (OAI)を利⽤して配信可能なので、ブロックパブリックアクセスを無効化しない
29EBSのデフォルト暗号化• EC2の設定ページからEBSのデフォルト暗号化を有効にする• デフォルトの暗号化キーを利⽤する
30EBSのデフォルト暗号化のコツ• マルチテナントで様々なライフサイクルのデータを扱う場合は、ライフサイクルに合わせてKMSキーを作成して個別に適⽤するといい(暗号化削除を実施するため)• https://aws.amazon.com/jp/blogs/news/data_disposal/
31パスワードポリシー強化• パスワードの最⼩⻑: 8⽂字• 少なくとも1つの⼤⽂字が必要• 少なくとも1つの⼩⽂字が必要• 少なくとも1つの数字が必要• 少なくとも1つの英数字以外の⽂字が必要• ユーザーにパスワードの変更を許可
32パスワードポリシー強化のコツ• ⼀番理想はIAM Userがいないこと• Okta / OneLoginなどIdPの基盤をAWSに限らず全体で使⽤し、ID管理とアクセス制御を集約するとベスト• 次点として1つのAWSアカウントにだけIAM Userを作るJumpアカウント⽅式も検討する• Assume Roleしないと権限がないため、万が一不正に利用されても何もできない
33デフォルトVPCの削除• 明⽰的な意図に合わせてVPCリソースを作成し、利⽤するためデフォルトVPCを削除• 既存環境であれば削除は慎重に
34デフォルトVPCの削除のコツ• 特にデフォルトセキュリティグループが危険なので利⽤しない• 合わせて、利⽤しているVPCのデフォルトセキュリティグループにあるインバウンドとアウトバウンドのルール両⽅とも削除する
35セキュリティサービス有効化 + チューニング• 有効化• GuardDuty• Security hub• Detective• IAM AccessAnalyzer
36セキュリティサービスのコツ• 集約可能なら複数AWSアカウントをまとめて集約する• 運⽤に組み込む
37セキュリティアラート整形 + 通知設定• Amazon GuardDuty / AWSSecurity Hub / AWS IAMAccess Analyzerからの通知を運⽤しやすい場所(チャットなど)に送る• ⾒やすく整形する
38セキュリティアラート整形 + 通知設定のコツ• 関係者が多い場所に通知してみんなに⾒えるようにする• 関係者の当事者意識が上がり、通知を減らし、セキュリティスコアを上げることがモチベーションに繋がる
39整形例: ⽇本語をできる限り⼊れる
401. セキュアなアカウント単体の原理のまとめ• AWSアカウント単体のセキュリティはSecurityHubの内容を中⼼にセットアップしていけばいい• ⾃動的にセットアップする仕組みが必要• 周りを巻き込む仕組みも必要
412. ベンディングマシンとアカウント運⽤
42ベンディングマシンとは︖• 新規のAWSアカウントを⽣成・セットアップする仕組みの概念• 必須のサービスを有効化したり、ベースラインの環境を構築したりする• 実現⽅法はCloudFormation StackSetsやTerraformやAWS Organizationsを組み合わせたり、AWS Control Towerを利⽤したりする
43CloudFormation StackSets• AWS OrganizationsがなくてもリージョンやアカウントをまたがるCloudFormation展開が可能
44合わせて読みたい簡単に全体を⾃動化https://dev.classmethod.jp/articles/cloudformation-stacksets-sample-sns-topic/
45合わせて読みたいAWS SummitでVisional様が発表した内容Terraformで全体へ展開https://dev.classmethod.jp/articles/aws-summit-online-2020-cus-06/
46AWS Control TowerAWSのベストプラクティスに従った構成でガードレールを効かせる仕組みAWSOrganizationsと連携する
47合わせて読みたい最近のControlTower事情はこちらで解説していますhttps://dev.classmethod.jp/articles/aws-control-tower-allin-2021/
48合わせて読みたいControl Towerから拡張した仕組みを展開するベンディングマシンをCDKでぽんと作れるやつhttps://dev.classmethod.jp/articles/aws-cdk-account-setup-of-ct-from-step-functions/
49合わせて読みたいTerraformとControl Towerを連携させてベンディングマシンを実現するAFTの記事https://dev.classmethod.jp/articles/aft-multi-regions-customization/
50維持の仕組みも考える• 展開したら終わりではない• 継続的な更新が必要なものもある• CloudFormationでUpdateStackをするなどで更新できるが、CFn未対応のリソースもある• Security Hubのコントロール設定とか• 各アカウントにIAM Roleを⽤意してスクリプトを流し込んだり、CFnのカスタムリソースを駆使して維持を検討する
51Security Hubの親⼦関係アクション単位で親から管理できることと、⼦供でしかできないことが決まっているhttps://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-accounts-allowed-actions.html
522. ベンディングマシンとアカウント運⽤のまとめ• なんでもいいからベンディングマシンを⽤意する• 自分たちの選択できる、使いやすいものを• CDKでもTerraformでもなんでもいい• 維持する仕組みを作る• 簡単にCloudFormationで展開できない設定などに注意する• どちらも作って終わりじゃないので継続的にブラッシュアップするつもりで作って使う
533. 最強にセキュアな運⽤
54⼤事なこと• 利⽤できるAWSサービスも使うツールもAWSアカウントの数も満たしたい基準もみんな違う• 世の中の情報は参考になるけど全く⼀緒にはならない• 上級者として、⾃分たちの環境ではどうするか、という観点で運⽤設計する
55セッションテーマ(再掲)⾃分たちの最強のAWS環境を作ろう
56実装と運⽤の参考例を紹介• ここでは下記を紹介する• 実装アーキテクチャ• 周りの巻き込み方• 参考にしつつ⾃分たちならどうするか考えてほしい
57実装アーキテクチャSecurity Hub集約とコンプライアンス違反Slack通知
58要件• 管理スコープ• 社内のAWSアカウントすべて• 本番用もあれば検証用もある• 管理条件• AWS Organizationsは利用しない• 管理対象の自由度を確保• Security Hubの集約はできる
59アーキテクチャSecurity HubはOrganizationsを利⽤しないでinviteして集約ベンディングマシンにて集約を⾏うついでに必要最低限のコントロール無効化
60アーキテクチャ各AWSアカウントの識別しやすい名前とアカウント種別、管理者のSlackIDをDynamoDBに登録違反がある場合に担当者にメンション(DMしない)
61アカウントの種類2種類に分類• 本番環境以外• 外部提供するプロダクトの開発・検証環境• 社内の個人検証環境• 本番環境• 外部提供するプロダクトの本番環境
62コントロールの対応⽅針コントロールに応じた3種類の対応⽅針を策定• 是正まで追跡• 検知項目が是正されるまで管理者が追跡する• 7日以内の修正目標• 通知のみ• ユーザーに通知のみ、是正するかは任せる• 通知したら抑制済みとし、セキュリティスコア対象外• 対応しない• 対応する必要なし、抑制済みにする
63コントロールの分類コントロールはある程度パターンが有り分類できる• 必須サービス・設定• 可⽤性確保• マルチAZやバックアップなど• ロギング• 通信中の暗号化• 保管時の暗号化
64ざっくり組み合わせ分類 本番 本番環境以外 備考必須サービス・設定是正まで追跡(基本的に)是正まで追跡(基本的に)実際はコントロール個別での判断が多い可⽤性確保 対応しない 対応しない 厳密なセキュリティ要件ではないため管轄外ロギング 是正まで追跡 対応しない 本番環境は⼤体のログは必須とする通信中の暗号化 是正まで追跡 是正まで追跡 現代のインターネットでは必須保管時の暗号化 対応しない 対応しない ポリシーと規制要件のためここでは管轄外
65その他⽅針メモ• 運⽤上煩わしいものは対応しない• VPCフローログとか• WAF適⽤は本番で通知のみ• WAFが不要な対象もあるため• OS以上のレイヤーの脆弱性管理は管轄外• SSMパッチコンプライアンスなど、別で管理する場合も多いため
66実装アーキテクチャ是正までの追跡⽅法
67⾊々悩んだことSecurity Hubの個別のFindingsのステータスを追跡する仕組みは結構⾯倒• 検知したらDynamoDBに登録する仕組み• ソートキーに検知日時を入れてデイリーでFindings一覧を収集してすべてのステータスを確認する実装• パーティションキーがほぼ固定になり分散されない• GetFindingsでFindingsIDを指定して回すのは20個ずつの制限がある
68頑張らないことにした代わりにセキュリティスコアを通知してこれを向上させることに注⼒してもらうことにしたSecurity Hub⾃体の画⾯で簡単に状況が確認できる←このスコアが達成状況100%を⽬指す
69Findingsの⾃動対応フロー追跡しない項⽬はすべてワークフローのステータスを抑制済みとする画⾯上で確認すべき項⽬が明確になる
70周りの巻き込み⽅セキュリティスコアの全体通知
71セキュリティスコアはAPIで取得できないので無理やり取得してみたhttps://dev.classmethod.jp/articles/get-control-finding-summary-by-boto3/
72セキュリティスコアランキングを掲載スコアが低い順じゃなくて、⾼い順Top10とかポジティブなランキングにする
73100%達成を盛⼤に祝うベースラインが100%の場合は達成した時に盛⼤に祝う
74周りの巻き込み⽅具体的なアクションをリクエストする通知
75すぐに次の⾏動がわかる通知を• いつまでに対応すればいいか• どの程度重要か(⾼中低)• 何を判断すればいいか• どのアカウント/リソースか• 対応⽅法は
76セキュリティグループが開いてるときの通知例• 24時間以内に対応してください• 重要度: ⾼• アタッチされているリソースに対するSSHを誰が利⽤しているか確認してください• 999999999999: ap-northeast-1: test-sg• SSHのポートを特定IPのみに絞るか、閉じてください。Systems Manager Session Managerを利⽤することでポートを閉じたままシェルを利⽤することも可能です。
773. 最強にセキュアな運⽤まとめ• Security Hubの全体管理をするスコープ・要件を定義する• やりすぎないように、任せるところは任せる• 独⾃の実装と、Security Hub⾃体の機能でまかなうところの境界線を決める• ポジティブにみんな参加できる雰囲気作りを頑張る
78全体まとめ
79全体まとめ• 単体のセキュアな設定もしつつ、組織の仕組みとして⾃動的にセキュリティが確保される運⽤を検討する• アカウント払い出しとベンディングマシンで全体に展開する基盤を作る• わかりやすい成果とポジティブな仕組みで周りを巻き込み、全員がセキュリティを向上できるようにする
80セッションテーマ(再再掲)⾃分たちの最強のAWS環境を作ろう
81やってみたらネクストアクションはコミュニティで事例の紹介Security-JAWSへの登壇はいかがでしょうか︖
82DevelopersIO 2022 謎解きクイズDevelopersIO 2022 イベントサイトの ○○○○○○ を⾒よう︕○○○○○○ の部分は下の画像がヒントだよ︕