hacomonoで頑張るSRE: クラウドガバナンス＆ク ラウドセキュリティ編 基盤開発本部 SRE グループ SRE チーム 小菅 航平 1


自己紹介 2
 - 小菅 航平(@Hukurou_kk) - ニックネーム:koskohei - 2023/06 入社 - 基盤本部 SRE グループ SRE チーム - 経歴 - 決済関連の フロントとバックエンドの開発、 運用、クラウド移行 - クラウドベンダーでの技術サポート

hacomonoについて 3


4


5


hacomonoのSRE の現在の業務内容 6


hacomonoのSRE活動の現在の業務内容 - サーバー構築、アップデートなどの各種フローの自動化、安定化 - サービスのパフォーマンス監視・改善 - クラウドリソースの運用コストの管理、改善 - SRE 観点からの製品仕様レビューや技術選定への参画 - インシデント時の多角的な調査分析、ポストモーテムの提案 - クラウドガバナンス観点に基づいた設定、改善 7


hacomonoのSRE活動の現在の業務内容 - サーバー構築、アップデートなどの各種フローの自動化、安定化 - サービスのパフォーマンス監視・改善 - クラウドリソースの運用コストの管理、改善 - SRE 観点からの製品仕様レビューや技術選定への参画 - インシデント時の多角的な調査分析、ポストモーテムの提案 - クラウドガバナンス観点に基づいた設定、改善 8


hacomonoのSRE活動の現状 “クラウドガバナンス観点に基づいた設定、改善 ” とは？ - 意図しない設定のリソースでも作成できる可能性がある状況の改善 - 意図しないリソースが作成された時の検知の仕組みの設定 - 万が一セキュリティインシデントがあった時の権限制御の設計 - 誰が何をしたかがわかる監査ログの取得、管理 - マルチアカウント戦略を立てつつ、サービスの利用を検討する - etc … 突き詰めていくと、運用の改善やセキュリティ観点での改善につながってくる 9


クラウドガバナンスとクラウドセキュリティに対する 施策 in hacomono 10


クラウドガバナンスとは？ 引用: セキュリティ、運用、コンプライアンス、コストの基準を順守しながら、迅速な作業を実現 
 クラウドガバナンスとは、組織がベストプラクティスに従うように導く一連のルール、プロセス、レポートです。 
 …
 組み込みのベストプラクティスとガバナンス基準を使用して、AWS オペレーションをガイドします。包括的な管 理により、規制要件を確実に満たします。また、クラス最高レベルの相互運用可能なサービスにより、マルチア カウント AWS 環境の一貫したガバナンスを実現します。 
 https://aws.amazon.com/jp/cloudops/cloud-governance/
 
 11


“クラウドガバナンスとは、組織がベストプラクティスに従うように導く一連のルール、プロセス、レ ポートです。”
 12
 🤔

“クラウドガバナンスとは、組織がベストプラクティスに従うように導く一連のルール、プロセス、レ ポートです。”
 
 
 13
 企業、組織でパブリッククラウドを利用する際にベストプラクティスを守るため、作成したルールや仕 組み、手段に加え言語化されたレポートなど取り組み全般を指すもの。

利用しているクラウドガバナンスのコントロールに役立つサービス 
 14


サービスの使用例 : Control Tower & Organizations 
 15
 - Account Factory によって新規アカウントの作成、組織への追加、 Config の自動有効化、CloudTrail のイベントロ グのAuditアカウントへの集約など一連の処理が自動化できるサービス。 - コントロールの利用による予防的統制、発見的統制の実現が可能。 - 予防(SCPベース)、検出(Config ルールベース)、プロアクティブ(CFn Guard ベース) - アカウント発行時に AFC(Account Factory Customization) によるアカウントカスタマイズ可能。 - ワークロードとLog Archive、Auditアカウントの区分けを行う。 - マルチアカウント戦略のベストプラクティス - https://aws.amazon.com/jp/builders-flash/202007/multi-accounts-best-practice/?awsf.filter-name=*all

16
 Management Account Security OU Prod OU Audit Account Log Archive Account Prod A Prod B

17
 Management Account Security OU Prod OU Audit Account Log Archive Account Prod A Prod B Control Tower & Organizations NEW! ①Control Tower によって新規アカウントを作 成される - CloudTrailによる証跡の記録 - Config の有効化と収集設定 - 適応されているガードレールの設定 - IAM Identity Center のユーザー追加 ※

サービスの使用例 : Config
 18
 - リソースの設定記録を自動で保存を行い、記録に対して Config ルールを使った評価が可能なサービ ス。監査対応の要項などを常にチェックできる。 - 独自要件に対応したリソース評価を行うカスタムルールを作成することも可能。 - Athenaのよる Config の設定履歴ファイルの検索は、リソースの増加原因などを調べる際に便利。 - アグリゲーターを使ったアグリゲーターアカウントへのリソースの設定記録の集約、ルール評価情報の 集約が可能。

19
 Management Account Security OU Prod OU Audit Account Log Archive Account Prod A Prod B Config ①各Configのリソースの設定 記録をアグリゲータを利用し てAudit アカウントにて収集

サービスの使用例 : CloudTrail
 20
 - ユーザーアクティビティと API 使用状況の追跡のためのイベントログを記録するサービス 。 S3,CloudWatch Logs に記録することができる。 
 
 - 長期的にイベントログを記録する場合、証跡の作成が必要となるが、組織の証跡を利用することで組 織内全てのアカウントのイベントログを一つのアカウントにまとめることが可能。 
 
 - 証跡のログの分析には Athena や CloudTrail Lakeを使用して分析する。 
 


21
 Management Account Security OU Prod OU Audit Account Log Archive Account Prod A Prod B CloudTrail ①各アカウントから イベントログを収集 ②ログアーカイブア カウントのS3 バケッ トに保存。

サービスの使用例 : IAM Identity Center 
 22
 - マルチアカウントでの権限を一元管理することが可能。外部 Idpをそのまま利用できるので会社の Idpを 利用してAWSアカウントへのサインインが可能。 - IAM ユーザーのアクセスキーのような長期的な認証情報の発行を防ぐ。アクセスキーが使用したい時 には一時的なアクセスキーの発行が可能。 → アクセスキーの漏洩を防ぎ、クラウドセキュリティの向上に繋がる。 ※権限の付与は申請制にすることで勝手に権限が付与されることを防ぎ、だれにいつ権限が当たったかを確 認できる状況に。

23
 Management Account Security OU Prod OU Audit Account Log Archive Account Prod A Prod B IAM Identity Center ①社員は必要な権限を申請し IAM Identity Ceneter を利用して 各アカウントにアクセス。

24
 Management Account Security OU Prod OU Audit Account Log Archive Account Prod A Prod B IAM Identity Center ②ワークロードに関係するアカ ウントには触れずに対象アカ ウントの権限のみで分析が可 能。

利用しているクラウドセキュリティの向上に役立つサービス 
 25


サービスの使用例 : AWS GuardDuty & AWS Security Hub 
 26
 - GuardDuty は CloudTrail のログや DNS クエリのログ、VPC フローログなどを分析した上で脅威検知を 行う。GuardDuty の利用の際には、全リージョンでの有効化が推奨されている。 - Security Hub はセキュリティ基準、コントロールを利用し、 ベストプラクティスの比較した評価が行える サービス。 - AWSサービス(GuardDuty や Inspector など)で作成された検出結果についてもアカウント、リージョンを 跨いで集約できる。その他 Sysdig のような一部のサードパーティ製品についても統合機能があり。 ASFF 形式であれば検出結果を自分で作成することも可能。

サービスの使用例 : AWS Security Hub 
 27
 - セキュリティ基準、コントロールを利用し、 ベストプラクティスの比較した評価が行えるサービス。 - AWSサービス(GuardDuty や Inspector など)で作成された検出結果についてもアカウント、リージョンを 跨いで集約できる。その他 Sysdig のような一部のサードパーティ製品についても統合機能があり。 ASFF 形式であれば検出結果を自分で作成することも可能。 - 新しくでた Automation ルールによって特定のリソースや検出結果に応じてアクションを起こすことが可 能となり、個々の対応なども柔軟に対応できる。

28
 Management Account Security OU Prod OU Audit Account Log Archive Account Prod A Prod B Security Hub GuardDuty etc.. ①各アカウントの全リージョンの GuardDutyの検出結果を収集した Security hubの検出結果を Audit Account のSecurity hub に収集 ②集約したリージョンの EventBridge ルールの API destinations をつかって slackへ通知

サービスの使用例 : Amazon CloudWatch 
 29
 - AWS リソース、または AWS 上で稼働するアプリケーションのモニタリングがメトリクス、ログの両面から 確認可能なサービス - ログ設計の見直しやアラートの設計を適切に行うことで各リソースのオブザーバビリティの向上を狙う。 - クロスアカウントクロスリージョン CloudWatch コンソールでは、クロスアカウント機能が有効化されたア カウント、もしくは組織内のアカウントのメトリクスやアラームを確認することが任意のアカウントにて可能 となる。

ガバナンス環境の管理方法 30


31
 Management Account Security OU Prod OU Audit Account Log Archive Account Prod A Prod B ①CDKをベースに作成したガバナンス 管理用のリポジトリにプルリクを作成 後、マージ。 ②CloudFormation StackSets を使い設定ファイル基づいた反 映を行う。

32
 ├── README.md ├── bin │ └── hacomono-management-account-cloudformation.ts ├── cdk.json ├── jest.config.js ├── lib // CDK のスタック設定群 │ ├── hacomono-management-account-cloudformation-selfmanaged-stack.ts │ ├── hacomono-management-account-cloudformation-servicemanaged-stack.ts │ ├── selfmanaged-stacksets-config.ts // 利用するテンプレートと対象のアカウント対象の設定ファイル │ └── servicemanaged-stacksets-config.ts // 利用するテンプレートと対象のアカウント対象の設定ファイル ├── package-lock.json ├── package.json ├── templates │ └── stacksets // 実際にCloudFormation StackSetsで利用するテンプレート │ ├── self-managed │ │ ├── create-notification-mechanism.yml │ │ ├── enable-security-hub.yml │ │ └── enabled-guardduty.yml │ └── service-managed │ └── create-iam-role-for-selfmanaged.yml ├── test │ └── hacomono-management-account-cloudformation.test.ts └── tsconfig.json

33
 // servicemanaged-stacksets-config.ts export const serviceManagedConfig = { "stacksetConfig" : [ { "templateName" : "<利用するテンプレートネーム >", "targetOuIds": ["<対象のOU id>"], "targetRegions" : ["ap-northeast-1" ], } ] }; // selfmanaged-stacksets-config.ts export const selfManagedConfig = { "stacksetConfig" : [ { "templateName" : "<利用するテンプレート名 >", "targetAccounts" : ["<アカウントID>"], "targetRegions" : ["ap-northeast-1" ], } ] };

今回の反映方法の工夫点
 34
 - CloudFormation のドリフト検知機能による Stack, StakcSetsが作成したリソースの手動変更の検知が可 能。 - Security hub が CloudFormation に対応したことで各アカウントの細かいコントロールの有効化、無効化 が調整できるように。 - 利用するサービス、コストに合わせて利用する機能を各アカウントで調整することができる。 - EventBridge コンソールなどで作成したルールは CloudFormationで出力できるので取り込むことができ る。 - CDKで作っておけば、後々 BLEA (Baseline Environment on AWS)とも統合可能？

全施策実施後の感想 35


全施策実施後に感じた利点
 36
 - Control Tower , Organizations を利用することでアカウント作成から運用に至るまでのプロセスが特に 工夫せずに整えることが可能。 CloudFormation StackSets を絡めることである程度柔軟にコントロール が効く。 - GuardDuty や Security Hubの検出結果、Config のリソースの設定記録を Auditアカウントに集約、 CloudTrail の証跡ログをLog Archive アカウントへ集約することでワークロードが動作するアカウントと 監 査や分析のアカウントを分離でき、まとめて確認することできる基盤が整いつつある。 - 各サービスを利用する時は AWS Cost Anomaly Detection を利用しておいた方が予想外の出費に反応 できるのでおすすめ。

今後の課題 37


今後の課題
 38
 - 現在も特定のアカウントではコストの観点で全てのサービスの導入ができていないアカウントもある。改 善に応じて再利用していきたい。 (Config , GuardDuty,Security Hub) - 全てのアカウントにいきなり当該構成を設定すると通知が恐ろしいことになってしまい形骸化しがち。何 から対応するかなどトリアージのルールは決めておくべきかも。 - ガバナンスの設定 = 組織でのベストプラクティスの集合知に当たるが、あらゆるドメインの知識、知見が 必要となるので全社員の協力が不可欠。 - => 常にガバナンスの設定を見直す、更新する機会があると良い。 - e.g. インシデント時に積極的にガバナンス観点で再発防止を提案する、見直す など。

まとめ 39


まとめ
 40
 - どの組織にもそれぞれのビジネスに合わせたベストプラクティスは蓄積されるものであり、クラウドガバ ナンスを通してクラウドセキュリティの観点、運用の観点から改善できるため、柔軟に対応できる基盤の 構築は必要不可欠。 - 特にスタートアップのようなパブリッククラウドの利用が選ばれやすい企業ほどクラウドガバナンス、セ キュリティの仕込みは必要になってくる。 - 特にスタートアップでは新規事業やピボッドが多いため、早め早めに組織周り、権限周りの環境作りを進 めておくことが長期的にみてラク、安心につながる。

41