[2021年版]AWSセキュリティ対策全部盛り[初級から上級まで]

解説と登壇時の動画を載せたブログは以下です。こちらを見てください。シェアもブログの方をお願いします。
https://dev.classmethod.jp/articles/aws-security-all-in-one-2021/
イベントページはこちら。
DevelopersIO 2021 Decade
https://classmethod.jp/m/devio-2021-decade/

Transcript

1. [2021年版] AWSセキュリティ対策全部盛り [初級から上級まで] 2021/10/6 AWS事業本部コンサルティング部 ⾅⽥佳祐 ハッシュタグ #devio2021
2. ⾃⼰紹介 ⾅⽥佳祐 ・クラスメソッド株式会社 AWS事業本部 シニアソリューションアーキテクト セキュリティチームリーダー AWS公認インストラクター ・Security-JAWS運営 ・好きなサービス: Amazon Detective 2 みんなのAWS (技術評論社)
3. 3 セッションテーマ すべての⼈にセキュリティを
4. 4 注意 スライドが多いから 細かいことは後で ⾒てにゃ
5. 5 アジェンダ 1. ⻑い前説 2. [初級]AWSを始める、セキュアに 3. [初級]システム作る、セキュアに 4. [中級]AWSのセキュリティを維持する 5. [中級]インシデントに対応する 6. [上級]組織全体でガバナンスを効かせる
6. 6 1. ⻑い前説
7. 7 ⻑い前説 なんで前説が 必要なんだにゃ︖
8. 8 なんで前説が必要なの︖ AWSのセキュリティ のまえに 情報セキュリティ
9. 9 なんで前説が必要なの︖ ⼩⼿先の技術 より 根本的なセキュリティの考え⽅
10. 10 なんで前説が必要なの︖ なんのためかわからないセキュリティ ではなく 正しく意味のあるセキュリティ
11. 11 なんで前説が必要なの︖ 後付けのセキュリティ ではなく 設計から組み込まれたセキュリティ
12. 12 なんで前説が必要なの︖ ひとりで頑張る ではなく 全員で取り組む
13. 13 なんで前説が必要なの︖ ⼈⼒で頑張る ではなく 精度の⾼い機械に任せる
14. 14 なんで前説が必要なの︖ オンプレミスの代わり ではなく クラウドの恩恵を受ける
15. 15 ⻑い前説の意味 ⼩⼿先じゃない 原則を押さえよう
16. 16 セキュリティで守るもの 守りたいものはなんですか︖
17. 17 守りたいもの(⼀部のざっくりした視点) • データ • 機密情報 • 顧客データ • 個⼈情報 • クレジットカード • コンテンツ • 利⽤者 • 個⼈情報 • アップしたコンテンツ • 会社 • 業務システム • 会社⾃体 • 企業イメージ • 従業員 • お⾦
18. 18 守りたいものはどこにあるか︖(例えば) • サーバー • データベース • ストレージ • PC • 物理的な紙
19. 19 守るものを把握する • どこにあるのか • 誰が責任者か • 誰が管理しているのか • 誰がアクセスできるのか • 今すぐに状態がわかるか すべて把握できていないと守れない 資産の洗い出し・特定して管理する まず洗い出し
20. 20 脅威とリスクを理解する どんな脅威がありますか︖
21. 21 情報セキュリティで扱う脅威(⼀例) • 情報漏えい • ⾦銭の搾取 • サービス停⽌ • 改ざん • なりすまし
22. 22 脅威を理解しリスクを理解する • 脅威と脆弱性がかけ合わさり リスクが顕在化する • 資産の価値でリスクの⼤きさ が変わる • 脆弱性を減らすことでリスク を⼩さくできる • リスクに応じてどのように対 策するか検討する 資産 脆弱性 脅威 リスク
23. 23 リスクを知り対策を知る(⼀例) • リスク: サーバーのデータが漏洩する • 根本対策: アクセス制御を徹底する • 補助対策: DLPを導⼊する 根本対策が 先だぞ
24. 24 設計にセキュリティを リスクがわかれば設計に反映できる • アクセス権限の洗い出し • 許可払い出しフローの管理 • 不要なサーバーポートの確認 • ソフトウェアの脆弱性管理 • ログの収集 • 送信元IPの集計 • 不審なIPのアラート やること と優先順 位が⾒え てくるぞ
25. 25 セキュリティの責任は誰にありますか︖
26. 26 セキュリティは誰の責任︖ • セキュリティ担当者だけではない • 開発者 • 運⽤者 • 監査⼈ • 経営者 • などなど • つまり全員セキュリティ担当 • 必要な⼈が必要な範囲⾏う(責任範囲) 関係ない⼈は いないぞ
27. 27 必要なもの 基本の知識 + 最新の情報
28. 28 セキュリティの原則 • 最⼩権限 • 多層防御 • 識別・認証・認可 • システムの堅牢化 • フェールセーフ • シンプルにする • 職務の分離 • Design for Failure • ⼈は間違える • などなど
29. 29 知らないと守れない • セキュリティの原理原則 • NIST CSF • 攻撃者の気持ち • AWSの特徴 • 便利なセキュリティ機能 • AWSの情報源 • 各AWSサービスUser Guideの「セキュリティ」ページ • JAWS-UG • ググる 常にキャッチ アップだ
30. 30 セキュリティ対策の進め⽅ 敵を知り ⼰を知り 適切な対応を
31. 31 合わせて読みたい 情報セキュリティについて深く知り たいなら情報処理安全確保⽀援⼠の 試験は丁度いいかも 網羅的で原理原則と技術のバランス がいい 最新の技術もある 個⼈的にはこの教科書が好き 試験受かってからも何度も読んでる https://www.amazon.co.jp/dp/479816867X/
32. 32 なぜAWSを利⽤するのか AWSのメリットはなんですか︖
33. 33 AWSが選ばれる10の理由 メリットを理解して有効に活⽤する https://aws.amazon.com/jp/aws-ten-reasons/
34. 34 2. [初級]AWSを始める、セキュアに
35. 35 課題 AWSなんもわからん けどテキトーに始めるか
36. 36 AWSの始め⽅ テキトーは絶対に ダメにゃ︕
37. 37 AWSの脅威 • 誤った情報の公開・アクセス許可 • AWSはローカルPCの環境や社内の検証環境ではない • 簡単に外部に公開して迅速に展開できる基盤 • 権限不備で情報漏えいが起きたり • 不正な攻撃者がアカウントを乗っ取ることも • 資⾦の浪費 • 従量課⾦で安く使い始められるけど、適切に管理しない と請求がすごいことに
38. 38 AWSを知る AWSを使い始める時にやることを押さえよう きちんと知れば 安全に使えるぞ
39. 39 合わせて読みたい 「AWS利⽤開始時に 最低限おさえておき たい10のこと」 最初に知るべきこと がまとまっている公 式の資料 https://pages.awscloud.com/eve nt_JAPAN_at-least-10- ondemand.html?trk=aws_event_ page
40. 40 合わせて⾒たい DevelopersIO 2021 Decadeで 動画セッション あります︕ https://classmethod.jp/m/ devio-2021-decade/
41. 41 最初にやること抜粋 • IAMユーザーを作ってルートユーザーをMFAで封印 • 必要なサービス有効化 • CloudTrail • Config • GuardDuty • Security Hub • IAM Access Analyzer • Detective • Well-Architectedフレームワーク読む
42. 42 IAM • Identity and Access Management • AWSにおけるアクセス制御の基本であり極意 • セキュリティの原則に従い利⽤ • 個別のIDを発⾏する • 最⼩権限 • MFA設定 • アクセスキーの利⽤は注意 • すべてのAWS利⽤者が理解する必要がある
43. 43 合わせて読みたい IAM再⼊⾨ やや古いがよくまと まっている https://dev.classmethod.jp/ar ticles/cm-advent-calendar- 2015-getting-started-again- aws-iam/
44. 44 合わせて読みたい すべての開発者はgit- secretsを導⼊する 意図せずアクセス キーをGitにコミット することを防⽌でき る https://dev.classmethod.jp/artic les/startup-git-secrets/
45. 45 CloudTrail • CloudTrailはAWS上の操作であるAPIを記録する • 誰がいつ何をどうしたか、全て記録される • いつログインしたか • 誰がサーバーを作成したか • いつ削除したか • ログはS3に保存しておく
46. 46 合わせて読みたい 最初にCloudTrailを 有効化する 全リージョンで⼀括 の設定が可能で必須 https://dev.classmethod.jp /articles/aws-cloudtrail- all-regions-on/
47. 47 Config • 各種AWSリソースの変更を記録・管理する • 時系列に変更を辿れる • セキュリティグループがいつ作られたか • いつどのように変更されたか • 関連性を辿れる • どのEC2と紐付いているか • どのVPCと紐付いているか • 問題ある設定を是正する
48. 48 合わせて読みたい AWS Configも最初 に有効化する リージョン毎の設定 なので全リージョン 回す グローバルリソース 記録は１つでいい https://dev.classmethod. jp/articles/aws-config- start/
49. 49 Well-Architectedフレームワーク 5つの柱に基づいたベストプラクティスを 理解できる
50. 50 合わせて読みたい 初めて読む⼈はこのブ ログから読むとよく理 解できる 熟練者もこのブログで 早引きできる つまり全員使うと良い ブログ https://dev.classmetho d.jp/articles/aws-well- architected-guide/
51. 51 2. [初級]AWSを始める、セキュアに まとめ 最初にやるべき・理解するべきことの 情報はいっぱいある しっかりキャッチアップしながら始める
52. 52 3. [初級]システム作る、セキュアに
53. 53 課題 AWSよくわからんけど オンプレとおんなじ セキュリティ対策でええやろ
54. 54 システムセキュリティ 原則はいっしょでも AWSで便利になるにゃ︕
55. 55 AWSでのシステム構築メリット • すぐに調達可能なリソース(スケーラビリティ) • マネージドサービスによる責任領域の低減 • リソース単位の詳細なアクセス制御(AWSレベル・ ネットワークレベル) • 簡単に利⽤可能なセキュリティ機能 • AWS WAF • Cognito • CloudFront
56. 56 AWSのメリットを活⽤する AWSで便利にできることは便利にやろう 様々なサービスを 知って活⽤しよう
57. 57 責任共有モデル 明確な責任範囲がある
58. 58 責任共有モデルの詳細 サービスによって責任 分界点が違う マネージドサービスは AWS管理部分が多くや りたいことに集中でき る 顧客責任部分も丸投げ ではなく便利な仕組み が提供されている
59. 59 ⼀般的なセキュアWeb環境 • 3層アーキテクチャ • EC2はプライベート • SSM Session Managerでア クセス(SSHしない、これ最 強。) • CloudFront + S3 + WAF • マルチAZ • Auto Scaling
60. 60 合わせて読みたい セキュアな環境の設 計から話した資料 初めてでも使える情 報満載 https://dev.classmethod.jp/artic les/jaws-days-2019-a-security/
61. 61 コンポーネント毎の話 • 次の順で説明 • コンピューティング • ネットワーク • データベース • ストレージ • OS/ミドル • アプリ • モニタリング/ログ
62. 62 コンピューティング(EC2) • EC2は直接パブリックに置かない(攻撃経路を無くす) • OS/ミドルのパッチは常に最新に(脆弱性管理) • SSHも可能な限りSession Managerを使う • 最低限のポートだけ開ける • ログを外部出⼒する(CloudWatchやS3) • マルウェア対策する • IAM Roleは最⼩権限に(SSRF対策) • 可能ならIMDSv2を利⽤する
63. 63 合わせて読みたい IMDSv2によりSSRF対 策が可能 万能ではないこと、OS/ ミドル/アプリ側でのサ ポートが必要な点は注意 https://dev.classmethod.jp/arti cles/ec2-imdsv2-release/
64. 64 コンピューティング(コンテナ) • ⾃前でDockerなどを動かさずにECS/EKSを利⽤す る(管理部分の委任) • AWSが管理している基盤のほうがセキュア • Fargateを利⽤する(管理部分の委任) • 信頼できるリポジトリを利⽤ • イメージをスキャンする(脆弱性管理) • ログを外部出⼒する(awslogs/FireLens) • NIST SP800-190もチェック
65. 65 合わせて読みたい コンテナセキュリティ の始め⽅や考え⽅がよ く分かるブログ https://dev.classmethod.jp/ articles/container-security- tools-and-docs/
66. 66 コンピューティング(Lambda) • 認証・認可されていないリクエストを受け付けない (アクセス制御) • 外部からのリクエストを処理する場合はAPI Gatewayをフロントに⼊れる • 強い権限のIAM Roleをアタッチしない(最⼩権限) • 脆弱性のあるパッケージを利⽤しない(脆弱性管理) • 実⾏数のクォータをモニタリングする(可⽤性)
67. 67 ネットワーク • 必要な単位でVPCを分割する(相乗りしない) • Security Groupで詳細なアクセス制御する • 最低限のポート • 最低限の送信元 • Security Group ID指定での制御(無駄にIP指定しない) • NACLでポリシー的なアクセス制御する • VPC EndpointによるセキュアなAWSアクセス
68. 68 データベース • RDS / DynamoDBなどマネージドなサービスを利 ⽤する(責任範囲) • マルチAZ / リードレプリカによる冗⻑化 • バックアップによる復旧可能性 • TLSによる通信経路の暗号化 • IAMによる管理アクセスの制御 • ユーザー毎データアクセス権限の最⼩化
69. 69 ストレージ(S3) • S3のアクセス制御機能の理解 • まずはパブリックアクセスブロック • バケットポリシー / ACL • バージョニング • オブジェクトロック(WORM) • クロスリージョンレプリケーション • アクセスポイント(アクセス制御の分割) • セキュリティベストプラクティス読む • https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/security-best-practices.html • ユーザーアップロードがあるならスキャン
70. 70 合わせて読みたい Cloud One File Storage Securityは サーバレスにS3をマル ウェアスキャンできる 素晴らしい仕組み https://dev.classmethod.jp/a rticles/trendmicro- introducing-security-for- cloud-object-storage/
71. 71 OS/ミドル • とにかく脆弱性管理 • 脆弱性診断だけではない • AWSならSSMインベントリ + Inspector + SSM パッチマネージャから始める • より快適なのはFutureVulsなど1つの基盤で⼀連の 脆弱性管理ができる仕組み
72. 72 合わせて読みたい SSM パッチマネー ジャを使いながら⾃ 動的にパッチを当て ていくアプローチの 1つ https://dev.classmethod.jp/arti cles/ssm-automation-patch- asg-instance/
73. 73 合わせて読みたい AWS側にログインしな くてもSSMと連携して⾃ 動的にパッチ適⽤が出来 る 発⾒した脆弱性をチケッ ト管理できて、発⾒から 修正まで⼀気通貫で出来 るネ申サービス https://dev.classmethod.jp/arti cles/ssm_integrate_and_patch _application_with_futurevuls/
74. 74 アプリ • アプリケーションセキュリティの責任はユーザー • セキュアに実装してください
75. 75 合わせて読みたい とりあえず徳丸本置いて おきますね https://www.amazon .co.jp/dp/479739316 5/
76. 76 アプリ(続き) • といっても⼤変なのでAWSの便利な機能を利⽤する • 認証基盤としてCognitoが利⽤できると⾃前で実装しなく て済む • Advanced Securityで認証強化 • アダプティブ認証(通常と違うログイン対策) • 侵害された認証情報(漏洩したパスワード対策) • AWS WAFを利⽤してフロントで攻撃を⽌められる • 認証情報は埋め込まないでSSMパラメータストアや Secrets Managerに保管する • ⾃動化された安全な仕組みでリリースする
77. 77 合わせて読みたい Cognito使うなら絶対 使おう https://dev.classmethod.jp/a rticles/aws-reinvent-cognit- asf-settings/
78. 78 合わせて読みたい AWS WAFの解説 マネージドルールを活 ⽤して楽に⾼度な機能 を利⽤しよう https://dev.classmethod.jp/ articles/fully-understood- aws-waf-v2/
79. 79 モニタリング/ログ • 現在の状態・過去の状態を確認することは必須 • 未来の状態も予測できる • CloudWatchメトリクスから必要な情報を得る • コンピューティングリソースの状態 • サービス・ビジネスメトリクス • ログから詳細なインサイトを得る • エラーなどを検知する • 最新のCloudWatch機能を活⽤する • 合成監視とか
80. 80 合わせて読みたい ダッシュボード参考例 https://dev.classmethod.jp/ar ticles/autoscalling-with- cloudwatch-dashboard/
81. 81 合わせて読みたい 合成監視(ユーザー視 点のシナリオベース 監視)で画⾯の差分を 検知したりできる https://dev.classmethod.j p/articles/cloudwatch- synthetics-visual- monitoring/
82. 82 合わせて読みたい Syntheticsなどの最新機能も含 めた様々な監視機能を学べる https://dev.classmethod.jp/articles/ introduction-of-one-observability- demo-workshop/
83. 83 合わせて読みたい S3に保存したログは Athenaで⾒る https://dev.classmethod.jp/a rticles/cloudtrail-athena- partition-projection-table/
84. 84 あとは⾃動化しよう CloudFormationなどで作業を⾃動化しよう 繰り返し作業が安定する 作業ミスが発⽣しない(⼈はミスする)
85. 85 ここまで初級です 初級 ちゃんとできてましたか︖
86. 86 3. [初級]システム作る、セキュアに まとめ それぞれのレイヤーで 原理原則を守って 便利なAWSサービスを駆使して 快適なセキュリティ設計・実装・運⽤
87. 87 システムのセキュリティ取り組み⽅ AWSのサービスはどんどんよくなります AWSをよく知り 継続的に改善しよう
88. 88 4. [中級]AWSのセキュリティを 維持する
89. 89 課題 いまちゃんとAWS全体が セキュアな状態かわからん
90. 90 AWSのセキュリティ維持 ⾃動でAWS環境を チェックするにゃ︕
91. 91 AWSのセキュリティ維持 • AWS Config RulesによりAWSの状態を確認し、定 義した状態から違反したらアラートを出せる • アラートから⾃動修復も可能 • Security HubはConfig Rulesを利⽤したセキュリ ティチェックが可能 • 詳細なアクセス制御の維持にはIAM Access AnalyzerやPermissions Boundaryを利⽤する
92. 92 AWSのメリットを活⽤する AWSで便利にできることは便利にやろう ⼈⼿で頑張るのは 愚策だぞ
93. 93 合わせて読みたい セキュリティチェックの 概念から様々な⼿法のメ リットデメリットなどま とまっています https://dev.classmethod.jp/art icles/2020-strongest-aws- securitycheck-practice/
94. 94 最強のセキュリティチェック⽅法を しっかり解説
95. 95 Configによる設定管理 Configでは現在の設定と、過去の変更の差分を時系列 に管理している
96. 96 Config Rulesのチェック項⽬ • ルールは2種類ある • AWSマネージドルール: ⽤意されている • カスタムルール: ⾃前のLambdaでチェックできる • マネージドルールの例 • SecurityGroupでSSHが0.0.0.0/0で許可されていないか • CloudTrailが有効か • S3バケットが暗号化されているか • RDSのバックアップが有効か • などなど100種類以上 • https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/managed-rules-by-aws-config.html
97. 97 Config Rulesから⾃動修復 • 検知だけではなく⾃ 動修復も可能 • ⼿動で開始する半⾃ 動修復と、検知次第 完全⾃動で修復も可 能 • 実態としてSSM Automationと連携 する
98. 98 合わせて読みたい 簡単にSSHの全開放を⾃ 動修復する設定 まずは検知からだけでも やってみよう https://dev.classmethod.jp/articles/au to-recovery-restricted-ssh-without- lambda/
99. 99 Config Rulesを活⽤した仕組み • Config Rulesは様々なチェックが可能 • これを応⽤するAWSサービスがある • Conformance Packs • CloudFormationのようにRulesをYAML/JSONで定義してデプ ロイできる • サンプルテンプレートが50個以上ある • Security Hub • 3種類のルールセットがある • ⾃動展開できる • 個別の検知抑制が可能
100. 100 セキュリティチェック⽅法 ⾊々あって迷うにゃ どれがいいにゃ︖
101. 101 セキュリティチェック⽅法 運⽤性と⼿厚さから Security Hubが オススメ
102. 102 セキュリティチェック⽅法 • Security Hubはセキュリティチェック運⽤の理想形 • 直感的なスコア表⽰ • 無効化・例外の設定管理 • AWSが最新のベストプラクティスを適⽤ • 「AWS の基本的なセキュリティのベストプラクティスコント ロール(AWS Foundational Security Best Practices)」の ルールが優秀 • 現状30リソースタイプ・121種類のチェック • 更新頻度が⾼い(リリースから約1年半で13回更新) • ⾃動修復ソリューション • マルチアカウントの集約
103. 103 直感的なスコア表⽰ 達成度が わかりや すい
104. 104 無効化・例外の設定管理 ルール・リソース単位のステータス管理
105. 105 対応リソースタイプ • ACM • Apigateway • AutoScaling • CloudFront • CloudTrail • CodeBuild • Config • DMS • DynamoDB • EC2 • ECS • EFS • ElasticBeanstalk • ELB • ELBv2 • EMR • ES • GuardDuty • IAM • KMS • Lambda • RDS • Redshift • S3 • SageMaker • SecretsManager • SNS • SQS • SSM • WAF
106. 106 ⾃動修復ソリューション マルチアカ ウント連携 した修復の 仕組みを展 開できる
107. 107 合わせて読みたい AWS基礎セキュリティ のベストプラクティス に対応した⾃動修復ソ リューションの解説 https://dev.classmethod.jp/a rticles/aws-security-hub- auto-remediation-asfbp/
108. 108 合わせて読みたい Security Hubの解 説とどんな⾵に運⽤ したらいいかをまと めています https://dev.classmethod. jp/articles/aws-security- operation-with- securityhub-2021/
109. 109 マルチアカウントの集約 イベントの 集約と管理 者の委任が できる
110. 110 合わせて読みたい AWS Organizations と連携することで快適 に集約管理できます https://dev.classmethod.jp/a rticles/security-hub- integrates-organizations/
111. 111 Security Hub以外を使う場合 • Security Hubも完璧ではない • Conformance Packsを利⽤する場合 • サンプルテンプレートを活⽤したい • ガリガリルールセットをカスタマイズしたい • ⾃動修復も独⾃で設定したい • カスタムルール(Lambda)を利⽤したい
112. 112 IAMのチェック
113. 113 IAMチェック⽅法 開発者にIAM発⾏の権限 を委任したいにゃ でも不安だにゃ
114. 114 IAMチェック⽅法 特に危ない外部共有 の設定はAccess Analyzerでチェック
115. 115 IAM Access Analyzer • 別のAWSアカウントから利⽤できるIAM Roleや不 特定多数からアクセスできるS3バケットなど、外部 共有のリソースを収集しチェックできる • 対応リソース • S3バケット • IAM Role • KMSキー • Lambda関数 • SQSキュー • Secrets Managerシークレット
116. 116 イメージはこんな感じ 検知結果は EventBridg e経由で通知 できる
117. 117 合わせて読みたい わかりやすい図と画像 でよく理解できるブロ グ https://dev.classmethod.jp/article s/iam-accessanalyzer-vs-iam- accessadvisor/
118. 118 IAMの権限昇格対策
119. 119 IAMの権限昇格対策 開発者がIAMの権限から ⾃⾝を昇格しそうにゃ
120. 120 IAMの権限昇格対策 Permissions Boundary で昇格を防⽌しよう
121. 121 Permissions Boundaryとは • IAMエンティティに追加で付 与できる • 元々のポリシー(アイデンティ ティベースポリシー)に加えて Permissions Boundaryで も許可されている権限しか実 ⾏できない • 作成するIAMにBoundaryを つけることを強要できる
122. 122 Permissions Boundaryのメリット 開発者の作成するIAMにBoundaryを強制する BoundaryでIAM周りの権限を制限する 権限昇格できなくなる
123. 123 合わせて読みたい Permissions Boundaryの使⽤例 https://dev.classmethod.jp/articl es/iam-permissions-boundary/ 他にも「Permissions Boundary workshop」で 検索すると参考になるものが あるよ
124. 124 4. [中級]AWSのセキュリティを維持する まとめ ⾃動で動くセキュリティチェックを駆使する アラートを受け取ったり⾃動で修復する ⼈⼿ではなく⾃動の仕組みで対処する
125. 125 5. [中級]インシデントに対応する
126. 126 課題 攻撃されているかわからん 気づいても対処の仕⽅がわからん
127. 127 AWSのインシデント対応 AWSの脅威検知は簡単にゃ 恐れずチャレンジするにゃ︕
128. 128 AWSのインシデント検知と対応 • Amazon GuardDuty(マネージドな脅威検知サービ ス)でいろんな脅威を検知 • EC2でコインマイニング • IAM不正利⽤ • S3への不審なアクセス • などなど • Amazon Detectiveで⾃動的にログを関連付けして 簡単に調査 • ユーザーガイドに対処⽅法がある
129. 129 AWSのインシデント対応 優秀なセキュリティ サービスで漏らさず 対応しよう
130. 130 インシデント対応の⼼構え
131. 131 インシデント対応の⼼構え • Security Hubなどで予防を頑張っていてもインシデ ントが起きる時は起きる • 予防だけではなくなにか起きた後迅速に対応するこ とも⾮常に⼤切 • NIST CSF的には検知・対応・復旧 • ⽇頃からこれらの準備をしておく
132. 132 NIST CSFとは • NISTサイバーセキュリティフレームワーク • セキュリティ体制づくりに活⽤できる
133. 133 NIST CSFのコア機能 • 5つのコア機能と各サブカテゴリに対応する対策がで きているかを⾃⼰評価する
134. 134 計画の作成
135. 135 AWSのインシデント対応の計画 ちゃんと計画 できてるかにゃ︖
136. 136 計画の第⼀歩 まず、どんなインシデントが起きるか知ろう どんな対応が必要か検討できる
137. 137 Amazon GuardDutyとは • 脅威検知サービス • CloudTrail / VPC Flow Logs / DNS Logsをバッ クグラウンドで⾃動収集(利⽤者の⼿間なし) • ポチッと有効化するだけ • IAM / EC2 / S3に関するインシデントを検知 • 脅威インテリジェンスと連携 • 機械学習による異常識別
138. 138 GuardDutyの検知内容(ほんの⼀部) • IAMタイプ • 不正ログイン • 漏洩したクレデンシャル利⽤ • CloudTrail無効化 • EC2タイプ • コインマイニング • C&Cサーバー接続 • SSHブルートフォース(受信 or 送信) • S3タイプ • バケット公開 • Torアクセス
139. 139 対応⽅法 GuardDutyのユー ザーガイドに検知 結果毎の対応⽅法 がわかりやすく記 載されている https://docs.aws.amazon.co m/ja_jp/guardduty/latest/u g/guardduty_finding-types- active.html
140. 140 初動対応計画 • 検知結果毎ざっくり3種類準備しておく • IAMタイプ • 認証情報を無効化する • EC2タイプ • EC2を隔離、保全、調査する • 調査は得意な会社に依頼できる準備でもいい • S3タイプ • アクセス権限を絞る
141. 141 IAMタイプの初動対応例 • IAM Userならアクセスキーを無効化・削除 • IAM Roleならセッションの無効化をポチ • CloudTrailで何をされたか調査
142. 142 EC2タイプの初動対応例 Security Groupを 変更して隔離 (in/out無し) AMIバックアップ 取得 サーバーやストレー ジ調査(できれば、 プロに任せたほうが いい)
143. 143 合わせて読みたい セキュリティ会社の 実際のEC2調査の例 https://ierae.co.jp/bl og/awsec2-hdd- analytics/
144. 144 S3タイプの初動対応例 パブリックアクセスブロックする
145. 145 合わせて読みたい GuardDutyの解説と どんな⾵に運⽤した らいいかをまとめて います https://dev.classmethod.jp/articl es/aws-security-operation-with- guardduty-2021/
146. 146 その他の計画 • エスカレーションフローなども決めておこう • 誰がいつまでにどこまで判断するか • 必要なログは収集しておこう • インシデント検知のアラートと⼀緒に⽬につくよう に対応することを出そう • いざという時は対応漏れが起きやすいのでチェック リストなどで簡単に実⾏できるようにしよう • 予⾏練習たくさんやろう
147. 147 クラスメソッドの障害対応例 2020年10 ⽉22⽇に 発⽣した AWS障害 の対応例
148. 148 合わせて読みたい 具体的なランブック オートメーション(⾃ 動対応)の実装例 https://dev.classmethod.jp/artic les/google-apps-script-slack- api-launch-01/
149. 149 合わせて読みたい AWS障害発⽣時のため の準備と対応の具体例 https://dev.classmethod.jp/articles/ technical-support-aws-failure- launch01/
150. 150 AWSのインシデント対応 対応⽅針がわかれば 怖くない 対応計画を作ろう
151. 151 詳細な調査が必要なケース
152. 152 詳細な調査が必要なケース • すべてのインシデントがGuardDutyの内容だけでわ かるとは限らない • 漏洩したIAMでどのようなことが実⾏されたか • EC2が何と通信したか • S3からダウンロードされたデータはなにか • IAM情報がどこから漏洩したか • などなど
153. 153 調査に必要なもの ログ
154. 154 何はともあれログ • GuardDutyは⾃動でログを収集して検知してくれる けど、ユーザー側にログを提供してくれない • 別途⾃分たちでも必要なものは保存しておく • 通常はS3に各種ログを出⼒する • 調査する時はAmazon Athenaを利⽤する • S3のオブジェクトレベルのログはCloudTrailにデー タイベントログ保存の追加設定が必要
155. 155 合わせて読みたい Athenaで CloudTrailのログ を調査する時のいい 設定(再掲) https://dev.classmethod.jp/ar ticles/cloudtrail-athena- partition-projection-table/
156. 156 しかしログの調査は⼤変 • ノイズが多い • ちょうどいいログクエリを探すのに⼀苦労 • 関連性を⾒出しづらい • クエリではなく、あらかた絞った状態でエクセルで検索 を駆使したり⽬grepしてがんばる • 動的な範囲の集計やりづらい • この時間範囲のこのユーザーの実⾏API数とか、ぐりぐり 動かしながらやりたい • 異常値を⾒つけにくい • どの観点で分析したらいいかわからん
157. 157 インシデントの調査 もっと簡単に 調査できないかにゃ︖
158. 158 できるよ Amazon Detectiveならね
159. 159 Amazon Detectiveとは • インシデント調査のサービス • VPC Flow Logs / CloudTrail / GuardDuty Findingsを⾃動で取り込む • わかりやすいグラフやマップで視覚化
160. 160 つまりこれが…
161. 161 こうじゃ︕
162. 162 Detectiveのいいところ 内部のグラフDBで関連付けしてくれる
163. 163 リソースの関連情報 リソースに関連す る情報を収集して リンクしてくれる 作成したユーザー や関連するイベン トを辿れる
164. 164 API実⾏履歴 関連するAPIを 集計してくれる 絞り込みもでき る API実⾏者単位 やIP単位で確 認できる
165. 165 直感的なマッピング どこから操作されているか GeoIPでマッピングしてくれ る
166. 166 合わせて読みたい 実際の画⾯とともにガッ ツリデモしているブログ 動きを⾒ながらより対応 イメージを⾼めよう https://dev.classmethod.jp/articles/a mazon-detective-investigation-demo/
167. 167 インシデントの調査 調査のツラミを Detectiveが 吸収してくれる
168. 168 調査の進め⽅ • Detectiveを使うことで調査が⼤幅に捗る • 何が起きているかの全体像把握 • 関連リソース把握 • 起因になっている事象を辿る • しかし最終的には⾃分でログを⾒る場合もある • ログを⾒る仕組みを⽤意するのも⽅法の1つ
169. 169 合わせて読みたい Amazon OpenSearch Service(旧 Elasticsearch)を利⽤ したAWSログの可視化 ソリューション OSSだよ いい感じだよ https://dev.classmethod.jp/articles /getting-started-siem-on-amazon- elasticsearch-service/
170. 170 SIEM on Amazon OpenSearch Service CloudTrailの可視化 こんな感じ ログイン失敗とか ルートのログインと かチェックしたい項 ⽬が最初からダッ シュボードに搭載さ れている
171. 171 SIEM on Amazon OpenSearch Service S3にログを⼊れればいい感じに取り込んでくれる
172. 172 合わせて読みたい freeeさんがSIEM on Amazon OpenSearch Serviceを1年運 ⽤した結果を紹介 しています 動画あり https://dev.classmetho d.jp/articles/security- jaws-22-report/
173. 173 おまけの情報 サードパーティのRadwareも 調査が捗ります
174. 174 Radwareによる原因調査 ⼀番左がインシデントの始まりです
175. 175 合わせて読みたい AWS上のインシデントをわかりやす いフロー図にして可視化できる Radware Cloud Native Protectorを使って攻撃された痕跡 を調査してみた https://dev.classmethod.jp/articles/getting- start-radware-cloud-native-protector/ AWSでコインマイニングされた原 因をRadware CNPのフロー図で わかりやすく調査してみた https://dev.classmethod.jp/articles/investig ate-coin-mining-with-radware-cnp/
176. 176 5. [中級]インシデントに対応する まとめ どんなインシデントが起こるか知り 準備・計画する ⼈⼒・⽬grepは⾟いので インテリジェントなサービスを 活⽤しよう︕
177. 177 6. [上級]組織全体でガバナンスを 効かせる
178. 178 課題 AWSアカウントや AWS利⽤者が増えて 管理が⾏き届かない
179. 179 AWSの全体管理 これまでの取り組みの 応⽤だにゃ︕
180. 180 AWSの全体管理 • ⾃動化された仕組みで必要なレベルを維持する • セキュリティチェック • CloudFormationによる⾃動化 • 全体でレベルを統⼀する • セキュリティ基準 • 対応計画
181. 181 AWSの全体管理 さらに全体管理の サービスも活⽤する
182. 182 AWSアカウントの集約管理
183. 183 全体管理に利⽤できるサービス • AWS Organizations • CloudFormation StackSets • AWS SSO • AWS Control Tower
184. 184 AWS Organizationsとは • 複数のAWSアカウント を束ねる仕組み • OUを定義して配下にア カウントをまとめられる • Service Control Policy(SCP)を利⽤して 強制的なアクセス制御が 可能
185. 185 SCPの例 • SCPの例 • 特定リージョン使⽤禁⽌ • CloudTrail無効化禁⽌ • GuardDuty無効化禁⽌ • S3バケット公開禁⽌ • タグのないリソース作成禁⽌ • https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/ orgs_manage_policies_scps_examples.html • 開発環境 / 本番環境 / 共⽤環境などで使い分ける
186. 186 合わせて読みたい Organizationsについて 必要な知識や関連サービ スについて⼀通り説明あ り https://dev.classmethod.jp/articles/l ets-study-aws-organizations-basic/
187. 187 合わせて読みたい OUの設計パターンを学 ぶのにおすすめのブログ 全部やらなくていいけど、 ⼀通り読んで何を採⽤す るか検討するといい https://dev.classmethod.jp/articles/ aws-organizations-best-practice/
188. 188 AWS Organizations連携 • 様々なAWSサービスと連携して簡単に全体管理でき る • AWS SSO • CloudFormation StackSets • GuardDuty • Security Hub • Systems Manager • CloudTrail • Config • などなど
189. 189 合わせて読みたい 管理している全AWSア カウントのEC2を⼀元的 に可視化できる https://dev.classmethod.jp/articles/ new-aws-systems-manager- explorer/
190. 190 CloudFormation StackSets • Organizationsがなくてもリージョンやアカウント をまたがるCloudFormation展開が可能
191. 191 合わせて読みたい 簡単に全体を⾃動化 https://dev.classmethod. jp/articles/cloudformati on-stacksets-sample- sns-topic/
192. 192 合わせて読みたい AWS SummitでVisional 様が発表した内容 Terraformで全体へ展開 https://dev.classmethod.jp/articles/a ws-summit-online-2020-cus-06/
193. 193 AWS SSO AWSアカウントの認証情報を集約できる シングルサインオンの仕組み
194. 194 合わせて読みたい よく分かる(かもし れない)図解 https://dev.classmethod .jp/articles/aws-sso- wakewakame/
195. 195 Jumpアカウント • AWS SSOを利⽤しなくてもSSOする⼿段はある • SAML連携 • JumpアカウントへのIAM User集約
196. 196 AWS Control Tower AWSのベストプラ クティスに従った構 成でガードレールを 効かせる仕組み AWS Organizationsと 連携する
197. 197 Control Towerの役割 • ID管理 • AWS SSOと連携した認証認可の集約 • ガードレール • SCPやConfig Rulesにより違反を防⽌・検知 • ベースライン展開 • CloudTrailやConfigなど⼀律で展開 • ログ管理・監視 • Log Archiveアカウントにログ集約 • Auditアカウントにアラート集約
198. 198 合わせて読みたい Control Towerの必要 性や背景、代替案などは 全部ここで説明していま す https://dev.classmethod.jp/ar ticles/jaws-days-2021- control-tower/
199. 199 合わせて読みたい Control Towerシ リーズ記事いろい ろあります https://dev.classmetho d.jp/tags/aws-control- tower/
200. 200 ガバナンスを効かせるのは 機能だけではない
201. 201 ガバナンスの意義 組織の⼈みんなで 協⼒にゃ︕
202. 202 CCoEによるクラウド活⽤最適化 • CCoE: Cloud Center of Excellence • クラウド推進の組織 • クラウド利⽤のノウハウを持つ・蓄える・提供する • 企業により定義や構成はさまざま • バーチャル組織で部⾨横断 • 情シスから派⽣ • DX推進チーム • クラウドのスピードに合わせて変わっていく
203. 203 CCoEの例
204. 204 CCoEの役割(例) • ガイドライン整備 • トレーニング提供 • 勉強会主催 • 共通インフラ整備 • 全体管理 • セキュリティ運⽤ • などなど
205. 205 合わせて読みたい CCoEの1つの実装例 ⽴ち上げ過程やどの ような⽅針で推進し たか解説されていま す https://dev.classmethod.j p/articles/shionogi- devshow/
206. 206 AWSに関わる様々な部⾨ • セキュリティ部⾨ • 定義されたセキュリティ設定の⾃動展開 • 調達部⾨ • ⾃動化された迅速なAWS環境払い出し • 監査部⾨ • ⾃動的にチェックされる定量的な評価 • みんな等しく効率化できる
207. 207 Cloud Audit Academy クラウドの監査について学ぶためのコンテンツ https://aws.amazon.com/jp/compliance/auditor-learning-path/
208. 208 AWSの全体管理 AWSに関わる⼈ みんなBuilderだ︕
209. 209 6. [上級]組織全体でガバナンスを効かせる まとめ 全体管理の仕組みと クラウドの恩恵を受ける組織の形で 効率よく全体管理しよう
210. 210 まとめ
211. 211 まとめ • 変わらないセキュリティの考え⽅を⾝につける • AWSのメリットと基本を押さえる • 便利なサービスを活⽤する • とにかく⾃動化 • 組織で最適化する • 全員Builderで全員セキュリティ担当だ