TOP>コラム一覧>AWSでマルチアカウント管理を考える(SCPでガードレールを作ろう①)

AWSでマルチアカウント管理を考える
(SCPでガードレールを作ろう①)

はじめに

こんにちは、園田です。
本記事は、「AWSでマルチアカウント管理を考える(SCPでガードレールを作ろう①)」となります。

過去の記事はこちら

AWSでマルチアカウント管理を考える(その1)
AWSでマルチアカウント管理を考える(その2)

本ブログはAWSでマルチアカウント管理を行う際の設計を行う際に、「こんなことを制限したいよねー。」というものになります。

そもそもマルチアカウント管理は、「ユーザ管理」と「利用者への制限」がメイントピックとなります。今回は「利用者への制限」を記載します。

ガードレール(コントロール)とは

本来の意味はAWS Control Towerにて持つ機能の一部となりますが、本ブログでは「セキュリティリスクを冒すような操作は実行させない」ということを実現するための機能としてガードレールと呼称することとします。

なお、ガードレールには

  • 「予防的ガードレール」(セキュリティリスクを冒すような操作は実行させない)
  • 「発見的ガードレール」(セキュリティリスクを冒すような設定が実施された場合に検知を実施する)

が存在しますが、今回の記事では「予防的ガードレール」をメインとして扱います。

正直、「検知をして修正するより、実施させない方がいいよね。」というのは多くの管理者の方が考えれていることではないでしょうか。ブログの後半では、「発見的ガードレール」をどうやって「予防的ガードレール」に変更していくかについて記載したいと思います。

SCPで予防的ガードレールを考える

サービスコントロールポリシー (以下、SCPと記載)はOrganizationsのOUに設定するものとなり、基本的に「何を制限するか(どのような操作をDenyするか)」を記載するものとなります。
(Organizationについては「AWSでマルチアカウント管理を考える(その2)」を参照ください)

SCPを考えるうえでポイントは「SCPで制御したものはrootおよびAdministrator権限より上位になる」という事です。どういうことかというと、例えばセキュリティ強化のため、「CloudTrailを削除・停止をさせない」ということを制限したい場合、SCPにてDeleteTrail、StopLogging、UpdateTrailを禁止(Deny)することで、CloudTrailの削除、停止が実施できないようにすることが可能です。
CloudTrailの場合、問題にはならないかもしれませんが、例えばCloudTrailの命名規則を変えたいとなった場合、そのままの状態ではrootやAdministrator権限を持っている管理者の方でもCloudTrailの削除、停止、変更が実施できません。

そのため、SCPを設定するといった場合、例外対応を実施したい場合、どのように運用をするのか(利用者から依頼があった際にどのように対応をするのか)を事前に定義しておく必要があります。

SCPを設定する際に決めておくこと

  • どのような制限をかけるのか
  • 例外対応を誰が実施するのか
    (制限をかけた操作については、事前に実施できる例外ユーザを定義しておくなど)
  • 例外申請について
    (利用者が禁止事項を例外的に実施したい場合、どのように申請するか、また許可する条件など)

どのようなガードレールを設定するか

どのようなガードレールを設定すべきかよくわからないといった場合、対応策としては以下の2つがあります。

  • 案1:想定されるリスクの洗い出しを実施する
  • 案2:すでに定義された基準(ベストプラクティスなどのドキュメント)を選定し、対策を検討する。

案1については網羅性を持たせるためには適切なソース情報、および時間が必要となります。また、あらゆる手動でリスクを洗い出すのは現実的ではないかと思います。(検討をする担当者全員がセキュリティおよびAWSに明るいという訳でもないかと思います)。
ということで、現実的には案2の「すでに定義された基準(ベストプラクティスなどのドキュメント)を選定し、対策を検討する。」という形になるかと思います。

このベストプラクティスについては一般的には「AWS Well-Architected」、もしくは「IAMセキュリティベストプラクティス」になるかと思います。

ただ、どちらも具体的な制限事項が記載しているという訳ではありませんので、実際にガードレールを設定する際に利用するというやり方は難しいと思います。

という訳で、実際にリスクがある事象を検知するツールを元にガードレールを定義するという方法が考えられます。リスク検知のツールとしてはサードベンダーのツールを利用するという方法もありますが、今回はAWS Security Hubを利用して、ガードレールを作るという事をしてみましょう。

まずはSecurity Hubのサービス画面にて「セキュリティ基準」→「AWS 基礎セキュリティのベストプラクティス v1.0.0」を「有効化」しましょう。
「AWS 基礎セキュリティのベストプラクティス v1.0.0」についてはAWSのベストプラクティスの設定のベストプラクティスとなっており、AWS上実施すべきでない操作を実施した際、検知できるルールとなっています。

Security Hubの画面

有効化を実施後、「AWS 基礎セキュリティのベストプラクティス v1.0.0」に表示される「結果を表示する」をクリックください。本設定にて監視している設定についてのダウンロードできますので、「ダウンロード」をクリックください。

ダウンロード画面(ダウンロードをクリックするとチェック項目がダウンロードできます)

これでSecurity Hubでどのような操作をリスクがある操作としているかの確認を実施することが可能です。早速、中身を見ていきましょう。

Security Hubでのチェック項目

Security Hubでのチェック項目については以下のような形となっています。

実際にダウンロードしたファイルをcsv形式で開いた場合の例

上記の画像を見てもらえれば分かるかと思いますが、Security Hubには「重要度」というものが存在します。重要度は「重要」、「高」、「中」、「低」となって、基本的には「重要」が最も危険度が高いと認識貰って間違いありません。

重要度の定義はこちら

  • 重大
    → この問題は、さらに悪化しないように直ちに修復する必要があります。

  • → この問題は短期的な優先事項として対処する必要があります。

  • → この問題は、中期的な優先事項として対処する必要があります。

  • → この問題には、独自のアクションは必要ありません。

参考
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/controls-findings-create-update.html

リスクがある行為については禁止する方が良いのはその通りですが、いきなり全てを検討するというのは現実的ではないため、まずは優先度が「重大」、「高」のものからチェックして、行為・設定を制限するのかというのを検討するのが現実的かと思います。

「重要」に関しては以下の通りとなります。本項目については予防的ガードレールをどのように設定するかについて、きちんと定義しておくべき項目と考えます。
なお、この設定項目については2023年6月度ものとなり、随時変更となる可能性があります。そのため、どのような項目がチェックされるかについては定期的に確認する必要があります。

Security Hubでの「重要」のチェック項目

ではこれらの項目に対しSCPにて予防的ガードレールを実施できるか、実施する場合どのように定義すればよいのかを考えていきたいと思います。

ちょっと長くなってしまったのでいったんここで切らせていただきます。 次回、「AWSでマルチアカウント管理を考える(SCPでガードレールを作ろう②)」でお会いしましょう。

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。

お問い合わせ

【著者プロフィール】

園田 一史(そのだ かずし)

伊藤忠テクノソリューションズ株式会社 クラウドアーキテクト

AWSの導入・運用支援サービス「CUVIC on AWS(キュービック オン エーダブリューエス)」の運営を担当。大規模DCのNW設計・構築、また国産IaaS型クラウドサービスの企画・導入・設計を歴任。物理・仮想基盤の設計、構築経験を活かし、AWSの導入・構築の支援をサポート。2019年~2022年APN Ambassadorに選任。

園田 一史(そのだ かずし)

TOP>コラム一覧>AWSでマルチアカウント管理を考える(SCPでガードレールを作ろう①)

pagetop