AWS Well-Architected セキュリティの柱 を利用した セキュリティリスクアセスメント方法について考えてみる

【connpass】
クラスメソッド x フォージビジョン x Fusic【AWS勉強会】
https://fusic.connpass.com/event/280126/
【youtube】
https://www.youtube.com/watch?v=syxM_6OyTd0&t=2500s

Transcript

1. AWS Well-Architected セキュリティの柱 を利⽤した セキュリティリスクアセスメント⽅法 について考えてみる 2023年5⽉26⽇ 株式会社Fusic 藤澤 亮平 1
2. ⾃⼰紹介 藤澤 亮平 - Work at - 株式会社 Fusic （フュージック） 技術開発第⼆部⾨ 所属 - ソフトウェアエンジニア - Skill - Ruby / Rails / Hanami - React / TypeScript - CloudFormation / Terraform / AWS CDK - TryHackMeを始めたばかりの セキュリティ初⼼者 - Career - 2023 Japan AWS Jr.Champtions - SNS - Twitter: @potaku_dev - Github: fujisawaryohei 2
3. Summary 3 Contents １. NIST CSFとAWS Well-Architected セキュリティの柱について ２. SecurityHubとの比較 ３. Well-Architected セキュリティの柱を 利用したアセスメントフローとスコア化 について ４. 結果的に得られたメリット
4. 01 NIST CSFと AWS Well-Architected セキュリティの柱について
5. Well-Archictected FrameWork 5 AWS Well-Architected の観点から設計原則やアーキテクチャのベストプラクティスへと 落とし込んだものです。設計・構築の指針として利用する事でクラウドのメリットを活用した アーキテクチャを設計・構築する事ができます。 写真: Well-Architected Frameworkについての概要ページ
6. Well-Architected セキュリティの柱 6 インフラ ストラクチャー 保護 お客様 データ ID・アクセス 管理 発見的統制 データ保護 インシデント レスポンス リスク コンプライアンス インフラ ストラクチャー 保護 図: セキュリティベストプラクティスで定義されている各領域 AWS Well-Architected Framework セキュリティの柱では あらゆるセキュリティ領域・側面からデータとシステムの保護に焦点を焦てた 設計原則やアーキテクチャのベストプラクティスが定義されています。 セキュリティの基礎 IDとアクセス管理 検知 インフラストラクチャ保護 データ保護 インシデント対応 アプリケーションのセキュリティ 図: Well-Architected セキュリティの柱で定義されている各領域
7. Well-Architected セキュリティの柱 7 インフラ ストラクチャー 保護 AWS Well-Architected Framework セキュリティの柱では、 あらゆるセキュリティ領域・側面からデータとシステムの保護に焦点を焦てた、 設計原則やアーキテクチャのベストプラクティスが定義されています。 No. 設計原則 内容 1 強力なアイデンティティ基盤を実装する 最小権限の原則を導入し、各 AWS リソースとの通信における適切な認可のもと、役割分担を徹底させます。 ID 管理を一元化し、長期間にわたって一つの認証情報を使用し続けないようにします。 2 トレーサビリティを実現する ご使用の環境に対して、リアルタイムでモニタリング、アラート、監査のアクション、および変更を行います。 ログとメトリクスの収集をシステムに統合して、自動的に調査しアクションを実行します。 3 すべてのレイヤーでセキュリティを適用する 複数のセキュリティコントロールを使用して深層防御アプローチを適用します。ネットワークのエッジ、VPC、 ロードバランシング、すべてのインスタンスとコンピューティングサービス、オペレーティングシステム、 アプリケーション、コードなど、すべてのレイヤーに適用します。 4 セキュリティのベストプラクティスを自動化する 自動化されたソフトウェアベースのセキュリティメカニズムにより、安全で、より速く、より費用対効果の高い スケーリングが可能になります。バージョン管理されているテンプレートにおいてコードとして定義および 管理されるコントロールを実装するなど、セキュアなアーキテクチャを作成します。 5 伝送中および保管中のデータを保護する データを機密性レベルに分類し、暗号化、トークン分割、アクセスコントロールなどのメカニズムを適宜使用し ます。 6 データに人の手を入れない データに直接アクセスしたりデータを手動で処理したりする必要を減らしたり、排除したりするメカニズムと ツールを使用します。これにより、機密性の高いデータを扱う際の誤処理、改変、ヒューマンエラーのリスクを 軽減します。 7 セキュリティイベントに備える 組織の要件に合わせたインシデント管理および調査のポリシーとプロセスを導入し、インシデントに備えます。 インシデント対応シミュレーションを実行し、ツールとオートメーションにより、検出、調査、復旧のスピードを上 げます。 図: Well-Architected セキュリティの柱で定義されている設計原則
8. Well-Architected セキュリティの柱 8 例えば、以下は「検知」という領域で定義されている 「サービスとアプリケーションのログ記録を設定する」という項目になります。 インフラ ストラクチャー 保護 例: 検知 > SEC04-BP01 サービスとアプリケーションのログ記録を設定する セキュリティの基礎 IDとアクセス管理 検知 インフラストラクチャ保護 データ保護 インシデント対応 アプリケーションのセキュリティ
9. NIST CSF 9 参考: NRI Secure Blog「【解説】NISTサイバーセキュリティフレームワークの実践的な使い方」 識別 防御 検知 対応 復旧 守るべきデータ, サーバーの識別・検討 ,,etc 保管しているデータの暗号 化やサーバーの防御 ,,etc ログの保管や検知機構 やSIEMの導入 ,,etc インシデントレスポンス デジタルフォレンジック マルウェア分析 ,,etc インシデント発生対象 のサーバーの復旧 ,,etc CSF（Cyber Cecurity FrameWork）とは、米国国立標準研究所（National Institute of Standards and Technology, NIST）が2014年に発行したサイバーセキュリティフレームワークです。 PCI・DSSやISMS, CIS Controlsと比較して汎用的でかつ体系的なセキュリティ対策を行う事ができます。
10. NIST CSFとWell-Architected セキュリティの柱 10 NIST CSFの6つの観点とWell-Architected セキュリティの柱をそれぞれ以下のような照合を行ってみました。 以下の事からもWell-Architected セキュリティの柱では、NIST CSFの観点が入っていると言えます。 識別 防御 検知 対応 復旧 インシデント対応 検知 ID・アクセス管理 インフラ保護 データ保護 明記はないが項目は 存在する 明記はないが項目は 存在する セキュリティの基礎 IDとアクセス管理 検知 インフラストラクチャ保護 データ保護 インシデント対応 アプリケーションのセキュリティ 図: Well-Architected セキュリティの柱で定義されている各領域
11. Well-Architected セキュリティの柱 まとめ Point 1 AWSセキュリティベストプラクティスの観点が含まれている。 Point 2 クラウドセキュリティにおける設計原則が定義されている。 Point 3 NIST CSFは汎⽤的で体系的なサイバー攻撃に特化したセキュリティフレームワーク。 Well-Architected セキュリティの柱にはNIST CSFの観点が含まれている。 11 Well-Architected セキュリティの柱については以下のような事が⾔えます
12. 02 SecurityHubとの⽐較
13. SecurityHub 13 AWS環境のセキュリティ・コンプライアンスチェックを⼀元的に実⾏・管理できるサービスです AWS標準のサービスと連携: 1. Amazon GuardDuty 2. Amazon Inspector 3. AWS Systems Manager 4. AWS Health 5. AWS Config 6. AWS Firewall Manager 7. AWS IAM Access Analyzer 8. Amazon Macie
14. SecurityHub アセスメント 14 現在以下の3つのセキュリティ標準のアセスメントを提供しています 標準名 業界特性 CIS AWS Foundations ITシステム全般 The Center for Internet Security (CIS) 基準 Payment Card Industry Data Security Standard (PCI DSS) 金融業界特有 The Payment Card Industry Data Security Standard (PCI DSS)基準 AWS Foundational Security Best Practices AWSインフラ全般 AWSセキュリティエキスパート基準
15. SecurityHub スコアリング 15 スコア機能も提供されており、各項⽬細かな評価値を参照できます
16. Well-Arhchitected セキュリティの柱との⽐較 16 SecurityHub Well-Architected セキュリティの柱 メリット ・AWSリソースの設定においてアセスメントが 早くて楽にできる ・Configと連携して利用する事ができるため 内部の人間により行われた設定ミスなどで 起きるセキュリティホールから身を守れる → 発見的統制、予防的統制を満たす事ができる ・AWS外の事がアセスメントの観点に 含まれているため、クラウド外の セキュリティ対策としてやるべき事も 明確になる ・漏れなくダブりなく網羅的で体系的な アセスメントができる ・ディフェンシブセキュリティの勉強になる デメリット ・AWS設定値を見てくれるがAWS外までは もちろん見てくれない ・とても時間がかかる （システムの規模にもよるけど） ・AWSにおける知見が結構必要 SecurityHub と Well-Arhchitected セキュリティの柱 ⽐較
17. SecurityHub まとめ Point 1 PCI・DSSやCIS Benchmarkといったグローバルなセキュリティ標準に 基づいたセキュリティチェックを⾏う事ができる。 Point 2 Well-Architected セキュリティの柱と⽐較するとよりAWS側に寄った セキュリティ領域のチェックが可能。 Point 3 漏れなくダブりないアセスメントを⾏いたい場合は、SecurityHubを利⽤しつつ、 Well-Architected セキュリティの柱を利⽤したアセスメントが最適。 17 SecurityHubについては以下のような事が⾔えます
18. 03 Well-Architected セキュリティの柱を利⽤ したアセスメントフローと スコア化について
19. アセスメントフローとアセスメントの基準について 19 領域 例: セキュリティ の基礎 中項目 例: AWS アカウントの 管理と分離 小項目 例: アカウントを 使用してワーク ロードを分ける 小項目を満たすための実装ガイダンスの 読み込み TODOチェックリストへの落とし込み TODOチェックリスト ☑ AWS Organizations を使用する ☑ AWS Control Tower を考慮する ☑ SCPを利用した一元的なポリシー管理 AWS環境の評価 ◯ 一部満たしている場合は△, 全て満たしていない場合は✕ No. 領域 No. 項目 No. 内容 既存環境 詳細・備考 1 セキュリテ ィの基礎 1 AWS アカウ ントの 管理 と分 離 1 SEC01-BP01 アカウントを使用して ワークロードを分ける ◦ ☑ AWS Organizations を使用する ☑ AWS Control Tower を考慮する ☑ SCPを利用した一元的なポリシー管理 2 SEC01-BP02 AWS アカウント をセ キュリティ保護する △ ☑ AWS Organizations を使用する ☑ AWS ルートユーザーの使用を制限する ☑ Organizationを利用していない場合は ルートユーザー用のAWS MFA を有効化する ☐ ルートユーザーパスワードを定期的に変更す る ☐ AWS アカウント のルートユーザーが使用さ れた 場合に通知を有効化する ☑ 新しく追加されたリージョンへのアクセスを 制限する ☐ AWS CloudFormation StackSets を検討する AWS Well-Architected Securityの柱 例 アセスメントシート Well-Architected セキュリティの柱を利用したセキュリティアセスメントを行いました。 どのセキュリティ領域を優先度を持って対応すべきか一目でわかるようにスコア化致しました。
20. AWSリスクレベルについて 20 AWSリスクとは Well-Architected Framework セキュリティの柱で記載されている セキュリティ要件が満たされていない場合のリスクレベルを 高・中・低 で 評価したものになります。 AWSリスクが高いもの = 最低限満たすべきセキュリティ要件 という形になります。 AWSリスク 高 中 低
21. AWSリスクレベルの重み付けについて 21 AWS環境のアセスメントで利用した ◯, △, ✕ と、AWSリスクレベル 高, 中, 低 のみでは どのセキュリティ領域を優先度高く対応すべきか判別する事が難しいと判断したため AWSリスクに重み付けを行い、スコアを算出しました。 AWS環境 ✕ = 3 AWS環境 △ = 2 AWS環境 ◯ = 1 AWSリスクレベル 高 = 3 9 6 3 AWSリスクレベル 中 = 2 6 4 2 AWSリスクレベル 小 = 1 3 2 1 AWSリスクスコア = AWSリスクレベル ✕ AWS環境のアセスメント結果 AWS環境 アセスメント結果 AWSリスクレベル 1 1 2 3 2 3 ✕ △ ◯ 低 中 高 AWSリスクスコアが 高いほどリスクが高い
22. Well-Architected セキュリティの柱 アセスメント例 22 SEC04-BP01 サービスとアプリケーションのログ記録を設定する https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_detect_investigate_events_app_service_logging.html AWSリスクレベルの 確認
23. Well-Architected セキュリティの柱 アセスメント例 23
24. Well-Architected セキュリティの柱 アセスメント例 24 1. TODOチェックリスト化 ☑ VPC Flow Logsの有効化 ☑ CloudTrail 管理イベントログの有効化 ☐ GuardDutyの有効化 ☐ SecurityHubの有効化 2. スコアに落とし込む AWSリスクレベル: 高, AWS環境: △ AWSリスクレベル 3 × AWS環境 2 = 6 1. 実装ガイダンスにログ有効化対象のAWSサービスが 記載されているため確認しながらTODO チェックリスト化 2. スコアに落とし込む 3. Excel シートなど表にまとめる No. 領域 No. 項目 No. 内容 AWSリスクレベル 既存環境 スコア 領域のスコア 項目のスコア 1 セキュリティの 基礎 1 AWS アカウントの管理と 分離 1 SEC01-BP01 アカウントを使用してワークロードを分け る 3 ✕ 9 43/72 9 2 SEC01-BP02 AWS アカウント をセキュリティ保護する 3 ◯ 3 2 ワークロードを安全に運用 する 3 SEC01-BP03 管理目標を特定および検証する 3 △ 6 31 4 SEC01-BP04 セキュリティ脅威に関する最新情報を入手 する 3 ✕ 9 5 SEC01-BP05 セキュリティに関する推奨事項を常に把握 する 3 ✕ 9 6 SEC01-BP06 パイプラインのセキュリティコントロール のテストと検証を自動化する 2 △ 4 7 SEC01-BP07 脅威モデルを使用してリスクを特定し、優 先順位を付ける 1 △ 2 8 SEC01-BP08 新しいセキュリティサービスと機能を定期 的に評価および実装する 1 ◯ 1 2 ID とアクセス管 理 1 ID 管理 9 SEC02-BP01 強力なサインインメカニズムを使用する 3 ◯ 3 53/126 22 10 SEC02-BP02 一時的な認証情報を使用する 3 ◯ 3 11 SEC02-BP03 シークレットを安全に保存して使用する 3 △ 6 12 SEC02-BP04 一元化された ID プロバイダーを利用する 3 ◯ 3 13 SEC02-BP05 定期的に認証情報を監査およびローテーシ ョンする 2 △ 4 14 SEC02-BP06 ユーザーグループと属性を活用する 1 ✕ 3 2 Permissions management 15 SEC03-BP01 アクセス要件を定義する 3 ✕ 9 31 16 SEC03-BP02 最小特権のアクセスを付与します 3 △ 6 17 SEC03-BP03 緊急アクセスのプロセスを確立する 2 ◯ 2 18 SEC03-BP04 アクセス許可を継続的に削減する 2 ✕ 6 19 SEC03-BP05 組織のアクセス許可ガードレールを定義す る 2 ◯ 2 20 SEC03-BP06 ライフサイクルに基づいてアクセスを管理 する 1 ✕ 3 21 SEC03-BP07 パブリックおよびクロスアカウントアクセ スの分析 1 △ 2 22 SEC03-BP08 リソースを安全に共有する 1 ◯ 1 3 検知 1 23 SEC04-BP01 サービスとアプリケーションのログ記録を 設定する 3 △ 6 24/36 24 24 SEC04-BP02 ログ、結果、メトリクスを一元的に分析す る 3 ✕ 9 25 SEC04-BP03 イベントへの応答を自動化する 2 ✕ 6 26 SEC04-BP04 実用的なセキュリティイベントを実装する 1 ✕ 3
25. アセスメント結果 例 25 No. 領域 No. 項目 No. 内容 AWSリスクレベル 既存環境 スコア 領域のスコア 項目のスコア 1 セキュリティの基礎 1 AWS アカウントの管理と分離 1 SEC01-BP01 アカウントを使用してワークロードを分ける 3 ✕ 9 43/72 （59%） 9 2 SEC01-BP02 AWS アカウント をセキュリティ保護する 3 ◯ 3 2 ワークロードを安全に運用する 3 SEC01-BP03 管理目標を特定および検証する 3 △ 6 31 4 SEC01-BP04 セキュリティ脅威に関する最新情報を入手する 3 ✕ 9 5 SEC01-BP05 セキュリティに関する推奨事項を常に把握する 3 ✕ 9 6 SEC01-BP06 パイプラインのセキュリティコントロールのテスト と検証を自動化する 2 △ 4 7 SEC01-BP07 脅威モデルを使用してリスクを特定し、優先順位を 付ける 1 △ 2 8 SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価 および実装する 1 ◯ 1 2 ID とアクセス管理 1 ID 管理 9 SEC02-BP01 強力なサインインメカニズムを使用する 3 ◯ 3 53/126 (42%) 22 10 SEC02-BP02 一時的な認証情報を使用する 3 ◯ 3 11 SEC02-BP03 シークレットを安全に保存して使用する 3 △ 6 12 SEC02-BP04 一元化された ID プロバイダーを利用する 3 ◯ 3 13 SEC02-BP05 定期的に認証情報を監査およびローテーションする 2 △ 4 14 SEC02-BP06 ユーザーグループと属性を活用する 1 ✕ 3 2 Permissions management 15 SEC03-BP01 アクセス要件を定義する 3 ✕ 9 31 16 SEC03-BP02 最小特権のアクセスを付与します 3 △ 6 17 SEC03-BP03 緊急アクセスのプロセスを確立する 2 ◯ 2 18 SEC03-BP04 アクセス許可を継続的に削減する 2 ✕ 6 19 SEC03-BP05 組織のアクセス許可ガードレールを定義する 2 ◯ 2 20 SEC03-BP06 ライフサイクルに基づいてアクセスを管理する 1 ✕ 3 21 SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析 1 △ 2 22 SEC03-BP08 リソースを安全に共有する 1 ◯ 1 3 検知 1 23 SEC04-BP01 サービスとアプリケーションのログ記録を設定する 3 △ 6 24/36 (66%) 24 24 SEC04-BP02 ログ、結果、メトリクスを一元的に分析する 3 ✕ 9 25 SEC04-BP03 イベントへの応答を自動化する 2 ✕ 6 26 SEC04-BP04 実用的なセキュリティイベントを実装する 1 ✕ 3 4 インフラストラクチ ャ保護 1 ネットワークの保護 27 SEC05-BP01 ネットワークレイヤーを作成する 3 △ 6 32/90 (35%) 12 28 SEC05-BP02 すべてのレイヤーでトラフィックを制御する 3 ◯ 3 29 SEC05-BP03 ネットワーク保護を自動化する 2 ◯ 2 30 SEC05-BP04 検査と保護を実装する 1 ◯ 1 2 コンピューティングの保護 31 SEC06-BP01 脆弱性管理を実行する 3 ◯ 3 20 32 SEC06-BP02 攻撃対象領域を縮小する 3 ✕ 9 33 SEC06-BP03 マネージドサービスを活用する 2 ◦ 2 34 SEC06-BP04 コンピューティング保護を自動化する 2 ◯ 2 35 SEC06-BP05 ユーザーがリモートからアクションを実行できるよ うにする 1 ✕ 3 36 SEC06-BP06 ソフトウェアの整合性を検証する 1 ◯ 1 5 データ保護 1 データ分類 37 SEC07-BP01 ワークロード内のデータを特定する 3 ◯ 3 52/117 (44%) 20 38 SEC07-BP02 データ保護コントロールを定義する 3 ✕ 9 39 SEC07-BP03 識別および分類を自動化する 2 ✕ 6 40 SEC07-BP04 データのライフサイクル管理を定義する 1 △ 2 2 保管中のデータの保護 41 SEC08-BP01 安全なキー管理を実装する 3 ◯ 3 14 42 SEC08-BP02 保管中に暗号化を適用する 3 ◯ 3 43 SEC08-BP03 保管時のデータの保護を自動化する 3 ◯ 3 44 SEC08-BP04 アクセスコントロールを適用する 1 ✕ 3 45 SEC08-BP05 人をデータから遠ざけるメカニズムを使用する 1 △ 2 3 伝送中のデータの保護 46 SEC09-BP01 安全な鍵および証明書管理を実装する 3 ◯ 3 18 47 SEC09-BP02 伝送中に暗号化を適用する 3 ◯ 6 48 SEC09-BP03 意図しないデータアクセスの検出を自動化する 2 ✕ 6 49 SEC09-BP04 ネットワーク通信を認証する 1 ✕ 3 6 インシデント対応 1 準備 50 SEC10-BP01 重要な人員と外部リソースを特定する 3 ◦ 3 27/63 (42%) 17 51 SEC10-BP02 インシデント管理計画を作成する 3 ◦ 3 52 SEC10-BP03 フォレンジック機能を備える 2 ✕ 6 53 SEC10-BP05 アクセスを事前プロビジョニングする 2 △ 4 54 SEC10-BP06 ツールを事前デプロイする 1 ◯ 1 2 シミュレーション 55 SEC10-BP07 ゲームデーを実施する 2 ✕ 6 6 3 イテレーション 56 SEC10-BP04 封じ込め機能を自動化する 2 △ 4 4 総計 246 231
26. 04 結果的に得られたメリット
27. Well-Architected セキュリティの柱を利⽤するメリット Point 1 クラウド領域外も含めた網羅的なセキュリティアセスメントが可能。 Point 2 セキュリティアセスメントの第⼀歩として気軽に始める事ができる。 （⼯数という観点では気軽ではない、、） Point 3 AWSにおけるクラウドセキュリティの勉強になる。 27
28. スコア化するメリットについて Point 1 対策すべきセキュリティ領域に優先度をつける事ができるようになった。 Point 2 クラウド環境のセキュリティ対策における進捗度を可視化する事ができた。 Point 3 セキュリティ対策について数字ベースでお客様への説明責任を果たす事が できた。 28
29. Special Thanks!!
30. ご清聴いただきありがとうございました Thank You We are Hiring ! https://recruit.fusic.co.jp/