$30 off During Our Annual Pro Sale. View Details »

hacomonoで頑張るSRE: クラウドガバナンス&クラウドセキュリティ編

hacomonoで頑張るSRE: クラウドガバナンス&クラウドセキュリティ編

基盤開発本部 SRE グループ SRE チーム
小菅 航平

【ハイブリッド開催】BtoB SaaSのSRE奮闘事例秋まつり
https://stmn.connpass.com/event/298576/

hacomono Inc.

November 22, 2023
Tweet

More Decks by hacomono Inc.

Other Decks in Technology

Transcript

  1. 自己紹介 2
 - 小菅 航平(@Hukurou_kk) - ニックネーム:koskohei - 2023/06 入社

    - 基盤本部 SRE グループ SRE チーム - 経歴 - 決済関連の フロントとバックエンドの開発、 運用、クラウド移行 - クラウドベンダーでの技術サポート
  2. hacomonoのSRE活動の現状 “クラウドガバナンス観点に基づいた設定、改善 ” とは? - 意図しない設定のリソースでも作成できる可能性がある状況の改善 - 意図しないリソースが作成された時の検知の仕組みの設定 - 万が一セキュリティインシデントがあった時の権限制御の設計

    - 誰が何をしたかがわかる監査ログの取得、管理 - マルチアカウント戦略を立てつつ、サービスの利用を検討する - etc … 突き詰めていくと、運用の改善やセキュリティ観点での改善につながってくる 9

  3. サービスの使用例 : 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
  4. 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 のユーザー追加 ※
  5. サービスの使用例 : Config
 18
 - リソースの設定記録を自動で保存を行い、記録に対して Config ルールを使った評価が可能なサービ ス。監査対応の要項などを常にチェックできる。 -

    独自要件に対応したリソース評価を行うカスタムルールを作成することも可能。 - Athenaのよる Config の設定履歴ファイルの検索は、リソースの増加原因などを調べる際に便利。 - アグリゲーターを使ったアグリゲーターアカウントへのリソースの設定記録の集約、ルール評価情報の 集約が可能。
  6. 19
 Management Account Security OU Prod OU Audit Account Log

    Archive Account Prod A Prod B Config ①各Configのリソースの設定 記録をアグリゲータを利用し てAudit アカウントにて収集
  7. サービスの使用例 : CloudTrail
 20
 - ユーザーアクティビティと API 使用状況の追跡のためのイベントログを記録するサービス 。 S3,CloudWatch

    Logs に記録することができる。 
 
 - 長期的にイベントログを記録する場合、証跡の作成が必要となるが、組織の証跡を利用することで組 織内全てのアカウントのイベントログを一つのアカウントにまとめることが可能。 
 
 - 証跡のログの分析には Athena や CloudTrail Lakeを使用して分析する。 
 

  8. 21
 Management Account Security OU Prod OU Audit Account Log

    Archive Account Prod A Prod B CloudTrail ①各アカウントから イベントログを収集 ②ログアーカイブア カウントのS3 バケッ トに保存。
  9. サービスの使用例 : IAM Identity Center 
 22
 - マルチアカウントでの権限を一元管理することが可能。外部 Idpをそのまま利用できるので会社の

    Idpを 利用してAWSアカウントへのサインインが可能。 - IAM ユーザーのアクセスキーのような長期的な認証情報の発行を防ぐ。アクセスキーが使用したい時 には一時的なアクセスキーの発行が可能。 → アクセスキーの漏洩を防ぎ、クラウドセキュリティの向上に繋がる。 ※権限の付与は申請制にすることで勝手に権限が付与されることを防ぎ、だれにいつ権限が当たったかを確 認できる状況に。
  10. 23
 Management Account Security OU Prod OU Audit Account Log

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

    Archive Account Prod A Prod B IAM Identity Center ②ワークロードに関係するアカ ウントには触れずに対象アカ ウントの権限のみで分析が可 能。
  12. サービスの使用例 : AWS GuardDuty & AWS Security Hub 
 26


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

    - AWSサービス(GuardDuty や Inspector など)で作成された検出結果についてもアカウント、リージョンを 跨いで集約できる。その他 Sysdig のような一部のサードパーティ製品についても統合機能があり。 ASFF 形式であれば検出結果を自分で作成することも可能。 - 新しくでた Automation ルールによって特定のリソースや検出結果に応じてアクションを起こすことが可 能となり、個々の対応なども柔軟に対応できる。
  14. 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へ通知
  15. サービスの使用例 : Amazon CloudWatch 
 29
 - AWS リソース、または AWS

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

    Archive Account Prod A Prod B ①CDKをベースに作成したガバナンス 管理用のリポジトリにプルリクを作成 後、マージ。 ②CloudFormation StackSets を使い設定ファイル基づいた反 映を行う。
  17. 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
  18. 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" ], } ] };
  19. 今回の反映方法の工夫点
 34
 - CloudFormation のドリフト検知機能による Stack, StakcSetsが作成したリソースの手動変更の検知が可 能。 - Security

    hub が CloudFormation に対応したことで各アカウントの細かいコントロールの有効化、無効化 が調整できるように。 - 利用するサービス、コストに合わせて利用する機能を各アカウントで調整することができる。 - EventBridge コンソールなどで作成したルールは CloudFormationで出力できるので取り込むことができ る。 - CDKで作っておけば、後々 BLEA (Baseline Environment on AWS)とも統合可能?
  20. 全施策実施後に感じた利点
 36
 - Control Tower , Organizations を利用することでアカウント作成から運用に至るまでのプロセスが特に 工夫せずに整えることが可能。 CloudFormation

    StackSets を絡めることである程度柔軟にコントロール が効く。 - GuardDuty や Security Hubの検出結果、Config のリソースの設定記録を Auditアカウントに集約、 CloudTrail の証跡ログをLog Archive アカウントへ集約することでワークロードが動作するアカウントと 監 査や分析のアカウントを分離でき、まとめて確認することできる基盤が整いつつある。 - 各サービスを利用する時は AWS Cost Anomaly Detection を利用しておいた方が予想外の出費に反応 できるのでおすすめ。
  21. 今後の課題
 38
 - 現在も特定のアカウントではコストの観点で全てのサービスの導入ができていないアカウントもある。改 善に応じて再利用していきたい。 (Config , GuardDuty,Security Hub) -

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