この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさんこんにちは、杉金です。
AWS re:Inforce 2022 セッション動画の視聴レポートです。SCPに関するセッション動画で、モルガン・スタンレー社によるSCPのベストプラクティスは必見です！実際のセッション動画では分かりやすい図であったり、詳細な説明をしてくださっていますので、レポートを読んで興味を持たれた方はぜひ動画をご覧ください。
セッション情報
セッション動画
セッション概要
In this session, learn how to use service control policies (SCPs) to allow your builders to innovate on AWS while staying within your organization’s security guidelines. By using SCPs effectively, you can help establish guardrails for your teams so that they can focus on innovating for your business. Learn about the basics of SCPs, situations where you can use them, how to test and roll them out across your AWS Organizations environment efficiently, and the top SCPs recommended for virtually everyone. (IAM202)
スピーカー
- Swara Gandhiさん
- Solutions Architect, Amazon Web Services
- Itay Cohaiさん
- Executive Director, Morgan Stanley
- Zulfi Haiderさん
- Vice President, Morgan Stanley
レポート
アジェンダ
- Overview of service control policies (SCPs)
- Using SCPs effectively
- Getting the most out of your SCPs
- Our top 5 recommended SCPs
- Morgan Stanley AWS organization/SCP evolution
- Lessons learned
- Use cases
Overview of service control policies (SCPs)
Set preventive guardrails with SCPs
ワークロードが増加し、ビジネスで使用するAWSアカウント数が増えるにつれて、所有するすべてのアカウントに適用できる集中制御の仕組みが必要となる。SCPはAWSが提供するツールの1つで、プリンシパルが組織内で何ができるかを制御するためのもの。あるアカウントのエンティティは明示的にアクセス権を与えない限り、別のアカウントのエンティティにアクセスできない。SCPはOrganization（組織）のどのレベルにも適用できるが、幅広く適用することを検討すること。SCPはアクセスを許可するものではなく、あくまでガードレールである。
SCPs define maximum allowable permissions
アクセスを許可するポリシーは2種類ある。
- IDベースのポリシー
- リソースベースのポリシー
IDベースのポリシーはIAMプリンシパルに適用するポリシーで、リソースベースのポリシーはS3バケットやSNSキューなどのリソースに適用するもの。IDベースのポリシーやリソースベースのポリシーによって、実際にS3バケットを作成したり、SNSキューを作成する。ポリシーによって利用者にアクセス権限を与えている。
SCPの場合はガードレールでアクセスを許可することはできない。最大限の権限を定義するだけである。従って、組織でこれら上記2種類のポリシーとSCPの3つすべてを実装している場合、有効な許可はこれら3つの組み合わせ結果である。あるアクションが3つすべてで許可されていれば、そのアクセスは機能する。
SCPs apply to your principals
SCPはプリンシパル、つまり組織が所有するIAMプリンシパルのみ適用される。例では2つのアカウント（アカウントA、アカウントB）があり、両方とも同じひとつの組織単位（OU）に所属している。S3バケットへのアクセスをTLS接続のみ受け入れたいとする。その場合、以下のポリシーを定義する。
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}このポリシーは、SecureTransportがfalseであれば全てのS3のアクションを拒否することを表す。このSCPをOUに適用する。アカウントAにIAMロールを作成し、アカウントBにあるS3バケットのオブジェクトにHTTPでアクセスしようとしている。バケットやロールに付けられたポリシーはパーミッションが与えられていると仮定する。この場合どうなるか。OUにSCPを適用していることに注目してほしい。このロールは組織に所属しているため、アクセスは拒否される。アカウントAはOUに所属しており、OUにはSCPが適用されている。IAMロールが組織内に存在していることが重要である。
今度はその逆で、IAMロールが組織に存在しない場合を見てみる。組織にアカウントが1つしかないとする。これをアカウントBとして、アカウントにオブジェクトの入ったS3バケットを用意する。先ほどと同様の以下のSCPを同じOUに適用する。
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}組織外からのクロスアカウントアクセスのケースを考える。クロスアカウントアクセスを許可する場合、両方（アクセス元AWSアカウントとアクセス先AWSアカウント）にポリシーが必要となる。アクセス先であるS3バケットのポリシーを以下に設定する。
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:ExternalAccount:role/RoleC",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::workload-B-Bucket/*",
"arn:aws:s3:::workload-B-Bucket"
]
}組織外部のAWSアカウントから入っていくるIAMロールCが「workload-B-Bucket」に対して任意のS3アクションを実行できるポリシーである。次にアクセス元の組織外部のAWSアカウントにIAMロール「RoleC」を用意する。RoleCのポリシーにも「workload-B-Bucket」に対するアクセスを許可するように以下のポリシーを設定する。
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::workload-B-Bucket/*",
"arn:aws:s3:::workload-B-Bucket"
]SCPが適用されていることを考慮して、RoleCからworkload-B-BucketにHTTPでアクセスを試みると結果はどうなるか？
この場合、アクセスは許可される。スライドのタイトルにある「SCPs apply to your principals」にある通り、SCPは本人しか適用されない。それでは、どのように回避するのか。
Restrict external principals using resource policy
このようなアクセスを拒否するポリシーを実装したい場合は、SCPではなく、リソースポリシーレベルで実装する必要がある。
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::workload-B-Bucket/*",
"arn:aws:s3:::workload-B-Bucket"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}RoleCは組織の一員ではないため、SCPは適用されない。アクセスはIDベースのポリシーとリソースベースのポリシーに依存する。
Using SCPs effectively
Use the right guardrail for the right controls
SCPの効果的な使い方として、以下の3つについて話をする。
- SCP
- Permission boundary
- Session policy
3つともガードレールポリシーで、アクセス権を与えものではなく許容される最大限のパーミッションを定義する。それぞれの影響範囲は異なる。SCPは、ルートレベルで適用した場合は組織内のすべてのアカウントに適用され、OUに適用した場合はアカウントグループに適用される。Permissions boundaryは、特定のプリンシパルにのみ適用される。もし、ある特定のIAMロールに対して権限の制限を行いたいのであれば、SCPではなくPermissions boundaryを使用する。セッションポリシーは、セッションに適用されるスコープダウンポリシーである。AWSアカウントで特定のアクションを実行するIAMロールに用いられ、その場でセッションポリシーを渡すことができる。一般的なポリシーがあり、誰かがS3へのアクセスのみを必要とした場合、S3だけを許可してその他すべてを許可しない。特定の役割に適した権限を持つことができる。影響範囲や拡張性を考慮して3つを使い分ける。
Getting the most out of your SCPs
実際にどのようなコントロールがSCPに含まれるべきか。SCPの書き方、最大限に活用するためのテクニックについて説明する。
- 1つ目のテクニック：継承を利用する
- 2つ目のテクニック：ポリシーを組み合わせる
- 3つ目のテクニック：ポリシーをコンパクトにする
Take advantage of inheritance for Deny
1つ目のテクニックは継承を利用することである。重要なポイントは、Denyのために継承を活用することである。組織内のSCPは、許可するポリシーと拒否するポリシーのどちらかを持つことができる。例えば、Denyがある場合にそれがそのまま連鎖的に継承される。Rootで拒否ポリシーを適用すると、配下に作成されたOUとアカウントに継承される。Rootレベルで許可ポリシーが設定されている場合、暗黙の了解はないため、OUおよびアカウントで許可する必要がある。
例を見てみる。アカウントAとアカウントBが同一の組織、OUに所属する。組織のRootに以下のポリシーを適用する。
{
"Version": "2012-10-17",
"Statement":[
{
"Sid": "ApprowvedServiceOnly",
"Effect": "Deny",
"Action": [
"robomaker:*",
"iot:*"
],
"Resource":"*"
}
]
}組織のRootにRoboMakerとIoTサービスを拒否するポリシーがある。OUに、以下の異なるSCPを適用する。
{
"Version": "2012-10-17",
"Statement":[
{
"Sid": "serverlessonly",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource":"*"
}
]
}OUに所属するアカウントは拒否をすべて継承する。アカウントAやアカウントBでは、ロボメーカーIoTサービスを利用することはできず、EC2 RunInstancesも実行できない。Denyは適用する場所によって継承される。
Combine policies
2つ目のテクニックは、ポリシーを組み合わせることである。組織内の各レベルで適用できるポリシー（SCP）の最大数は5つである。Rootレベル、OUレベル、アカウントレベルで5つのポリシーを持つことができる。そのため、複数のポリシーを組み合わせる必要がある。
SCPを使い始めるときは、フルアクセスポリシーで始まる。すべての利用者がフルアクセスできることを意味するものではない。SCPレベルのガードレールがなく、IAMに頼っているということに過ぎない。
2つのポリシーを組み合わせる例を挙げる。まず、1つ目のポリシーを以下とする。
AWS full access policy
{
"Version": "2012-10-17",
"Statement":[
{
"Effect": "Allow",
"Action": "*",
"Resource":"*"
}
]
}2つ目のポリシーは、S3とSecurity Hubの拒否を含むものである。
{
"Version": "2012-10-17",
"Statement":[
{
"Effect": "Deny",
"Action": "s3:DeleteBucket",
"Resource":"*"
},
{
"Effect": "Deny",
"Action": "securityhub:Disable*",
"Resource":"*"
}
]
}この2つのポリシーを組み合わせると次のようなポリシーとなる。
{
"Version": "2012-10-17",
"Statement":[
{
"Effect": "Allow",
"Action": "*",
"Resource":"*"
},
{
"Effect": "Deny",
"Action": [
"s3:DeleteBucket",
"securityhub:Disable*"
],
"Resource":"*"
}
]
}組み合わせることでポリシーの数を節約できる。ただし、期待している意図と変わらないことに注意すべきである。
Compact your policy
3つ目のテクニックは、ポリシーのコンパクト化である。コンパクトにするための方法は3つある。
- Use AWS Management Console
- Remove white spaces
- Shorten:"Sid"
SCPの最大サイズは5,120byteである。マネジメントコンソールを使用している場合は、ポリシーを保存する際にスペースを自動的に削除する。CodePipelineを使用してSCPをデプロイする場合は、CICDパイプラインでスペース削除を実装する。
SIDはステートメントIDのことで、任意の項目である。特定のポリシーが何をするものなのか等のリファレンスを入れるのに使える。ポリシーのサイズが足りなくなったら、SIDを削除するか、短くするとよい。もしくはSCPをデプロイする前にコードから取り除く方法もある。
Our top 5 recommended SCPs
Prevent leaving the organization
（本記事最後の方にあるResourcesにて各SCPのリンクを記載しています）
1つ目は、組織からの離脱を防ぐことである。SCPを適用する場合、組織内のすべてのアカウントが組織の一部である必要があり、その場合のみSCPが適用される。そのため、組織から離脱するアカウントを拒否するポリシーを適用する。組織にはメリットがある。一括請求や割引、異なるアカウント間で環境のセキュリティと監査を一元的に行える。そして、SCPを使用して中央制御を実装できる。
Only allow usage of approved AWS Regions
2つ目は、承認されたAWSリージョンのみを使用することである。AWSでは、リソースを作成したい場所をグローバルに選べるが、一部地域のみで事業を展開している企業にはコンプライアンスの必要性がある。その場合に利用可能なリージョンを制限する。リージョン制限から除外したいグローバルサービスは、NotAction条件を利用する。
Prevent usage of the root user
3つ目は、rootユーザーの使用を禁止することである。rootユーザーの使用を必要とするタスクは、実際にはごくわずかである。ルートユーザーの使用を拒否するポリシーを適用すること。
Prevent disabling security services
4つ目は、組織内のセキュリティサービスを無効化しないことである。CloudTrail, Config, Security Hubで拒否するアクション例を挙げる。
- AWS CloudTrail
- cloudtrail:DeleteTrail
- cloudtrail:PutEventSelectors
- cloudtrail:StopLOgging
- cloudtrail:UpdateTrail
- AWS Config
- config:DeleteConfiguration*
- config:DeleteDeliverryChannel
- config:DeleteRetention*
- config:PutConfiguration*
- config:PutDeliveryChannel
- config:PutRetention*
- config:StopConfiguration*
- AWS Security Hub
- securityhub:Disable*
- securityhub:DIssociate*
- securityhub:DeleteInvitations
- securityhub:DeleteMembers
もし、これらのサービスや他のセキュリティサービスを使用している場合は、サービスの無効化を拒否するSCPが必要である。
Protect your sensitive Amazon S3 buckets
5つ目は、センシティブなS3バケットに対する操作を防止する。本番用のS3バケットに機密データが保管されているとする。組織内の誰にもS3バケットを削除したり、S3バケットの公開アクセス設定を変更したり、S3バケット内の画像やオブジェクトを削除する権限を与えたくはない。その場合に関連するアクションを拒否してS3バケットを保護する。
- Specific S3 bucket deletion
- s3:DeleteBucket
- s3:DeleteBucketPolicy
- S3 public access settings
- s3:PutAccountPublicAccessBlock
- s3:PutBucketPublicAccessBlock
- s3:PutObjectVersionAcl
- s3:PutObjectAcl
- Object and version deletion
- s3:DeleteObject
- s3:DeleteObjectVersion
- s3:DeleteObjectTagging
- s3:DeleteObjectVersionTagging
- s3:PutLifecycleConfiguration
Morgan Stanley AWS organization/SCP evolution
モルガン・スタンレーは、グローバルな金融機関である。セキュリティとコンプライアンス、そしてお客様のデータ保護に深く配慮しているからこそ、SCPの導入に踏み切った。OrganizationsとSCP利用の道のりについて少し話をする。
取り組み始めた当初は、AWS Organizationsの構成は自分たちの組織図をコピーしたような作りにした。これは、これまでLDAPで行ってきたようことと同じような方法である。部門があり、部門によって利用するかを決める。それが理にかなっていると信じていた。
Then comes a re-org
組織再編、それは大きな組織ではよくある。A部門はA++部門に名前が変わり、B部門はC部門に統合される。D部門は存在しなくなった。組織再編によって、Organizationsの構成として間違った道を歩んでしまったことに気づいた。
- 学んだ教訓
- OUは、頻繁に変更されないものをベースとすること
- OUは、人事構造ではなく技術的なコントロールに基づくものでなければならない
私たちがやったようなことをしないように。実際の組織に基づいてOrganizationsを構成しないようにすること。会社の組織構造は変わるのである。時間と共に変化するものに合わせないこと。それより技術的なコントロールに合わせる方がよい。インターネットへの公開度合いやセキュリティポリシーに基づいてワークロードをグループ化したり、地域や同じワークロードに対応するサービス群に基づいてグループ化することもできる。
That's how we deployed deny policies
組織図に基づくとビジネスユニットやOUによってポリシーは当然異なる。AというOUではデータベースを使用禁止、BというOUではLambdaを使用禁止にする。人事部、経理部、請求書発行部などのサブ部門についても検討した。その結果、何が起こったか。
Then comes troubleshooting
利用者から「アクセスが拒否された、利用できない」という問い合わせを受けることがある。ごく一般的な話で、できないはずがない。どこで制御されているSCPかを確認しようとした。幸いなことにSCPで何かが拒否された場合、少なくともエラーメッセージにSCPで拒否されていることが分かる。しかしアカウント、OU、Rootレベルのどこに適用されているSCPか、すべてを片っ端から確認する必要があった。
- 学んだ教訓（拒否の方針を次のようにする）
- Single layer
- Immutable
- Highly guarded
1つ目のポイントは、すべての方にお勧めする。SCPは一箇所で管理されていれば、見なくてもどこに何があるかがわかる。
2つ目のポイントは「不変性」で、SCPが変更されないようにする。Rootアカウントを使うべきときに、ポリシーを付けたり外したりするのは、良いポリシーとは言えない。何かをするためにセキュリティポリシーを変更したい場合は、アカウントを他のOUに移動すべき。ルートが許可されるステージングエリアを用意する。そこに移動して、そこで作業をして、終わったらまた移動する。そうすることで、ポリシーを付けたり外したりする必要がない。庭に柵があって、柵を撤去したり再び設置したりしないのと同じ理屈である。2つ目のポイントの側面として、コードの不変性についても話をする。SCPは手作業で編集してはいけない。SCPはコードとして成果物として管理されるべきである。デプロイのパイプラインを構築するために、実際に役立つツールとしてのインフラは十分にある。
そして、それが3つ目のポイントへとつながっていく。SCPは重要な防衛線の一つであることは間違いないが、ガードできない。SCPが1つの場所にあり、コードとして維持されているならばモニタリングすべき。リポジトリにあるSCPのコードと実際に適用されているSCPが同じあることを監視すべきである。
And then we run out of policy space
- 学んだ教訓（Denyポリシーは）
- 少なく
- よりシンプル
- 粒度を粗く
拒否のポリシーが細かすぎる or 長すぎる場合、SCPにはふわしくない。
SCPには5Kのサイズ制限がある。すべてをSCPに置き換えたことで、ポリシーが肥大化していった。同じ目的であってもポリシー1がポリシー2に変わっていく。すべてのアクセス制御がSCPである必要はない。先ほどの説明にあったようにリソースベースのポリシーやIAMに設定することも可能である。permissions boundaryに記載することも可能である。また、Infrastructure as codeを使って、インフラのコードテンプレートに焼き付けることができる。TerraformモジュールやCloudFormationスタックを使用しているかどうかに関わらず、この制御を簡単に組み込むことができる。
SCPは常に私たちを守ってくれるわけではないため、SCPはできるだけ粒度を粗くする。
セキュリティ設計の原則「Economy of Mechanism」を重視する。
（執筆者メモ 参考:セキュリティ設計の原則「Economy of Mechanism」について）
さて、このような旅と進化を経て、私たちがたどり着いたのは、このようなものである。
（スライドの図にて変更後のOU構成を説明:文章での説明が難しいため割愛します）
Enforcing out guardrails
管理アカウントと拒否ポリシーに少し焦点を当てましょう。 これらは、ルートで持っている拒否のポリシーの一部である。
- GuardRail-Deny-non-operating-Regions(Deny actions outside the authorized AWS regions)
- GuardRail-Deny-exFilltration(Deny ability to store / upload to Data sources outside the org-id)
- GUardRail-ThouShallNot(Deny actions that violate key security and operational controls)
- GuardRail-Restrics-OUs(Deny actions no authorized for the parent OU)
1つ目は、先ほども発表したもので利用するリージョンを限定するものである。金融業界では様々なコンプライアンス上の理由から非常に重要である。ほとんどの業界では、欧州のGDPRであろうと、HIPAAであろうと、どの地域にも類似のものがある。2つ目は、データ流出の拒否についてである。これは"aws:ResourceOrgID"を利用することで実現できる。後ほどの説明で焦点を当てる。3つ目は、やってはいけないことの一般的なSCPを指す。4つ目は、先ほどの説明にもあった外部からのアクセス制限で、"aws:ResourceOrgPaths"を使用する。後ほどの説明で深く説明する。
Organizing out Organizations deployment
先ほどパイプラインの話とSCPをコードとして管理する話をした。ここでは職務の分離に焦点を当てる。SCPを作成・デプロイするチームは、SCPを使うチームであってはならない。SCPをデプロイするSecOpsチームとアプリケーションをデプロイするDevOpsチームは異なるパイプラインを使用する。
SecOpsパイプライン
- SCP in Source Control
- Review Process
- IaCによるSCPのデプロイ（AWS Organizationsにデプロイ）
DevOpsパイプライン
- Infrastructure as Code
- Review Process
- IaCによるデプロイ（対象のAWSアカウントにデプロイ）
Use cases
SCPをどのように使うかについて、ユースケースとしてもう少し深く掘り下げて考える。
UC1:Organizations housekeeping
- アカウントライフサイクルの全フェーズをコードで管理する。"CreateAccount "と "CloseAccount "の権限は、オートメーションプリンシパルのみが利用可能とする。人の手では、アカウントを作成や閉じることはできない
- SCPのコンテンツをコードで展開する
- 私たちのOrganizationsは、招待制ではなく誕生制（アカウント作成）である
- メンバーアカウントは組織から離れることができない/組織から削除できない
- "LeaveOrganizaion","InviteAccountToOrganization","RemoveAccountFromOrganization"などのパーミッションは永久にブロック
組織を離れたり、組織から削除されたアカウントはSCPによるガードレールを回避するため、セキュリティ上のリスクが生じる。アカウント閉鎖の事故は運用に影響を及ぼす。どちらの操作もAWSコンソール上で簡単に2回クリックするだけで利用できるため、予防的なコントロールが必要である。
アカウント誕生制とは、組織に属するすべてのアカウントが、一貫したセキュリティのベースラインを使用して作成されたことを確認するためのものである。組織からアカウントを削除する権限は管理アカウントに存在し、SCPでは制御できないため、permissions boundaryによってブロックしている。permissions boundaryでブロックしているのは、ヒューマンプリンシパルによるアカウントを閉じる機能で、コードを通じてのみアカウントを閉じることができる。
UC2:We explicitly allow services per account
アカウントごとにサービスを明示的に許可する
- AWSのサービスは日々増え続けている
- アカウントレベルでのFullAWSAccessを付与しない
- サービスを許可する前に、各サービスのセキュリティへの影響をレビューする時間を確保している
- 200以上あるサービスのうち、1つのアカウントで30以上のサービスを利用することは通常想定されない
すべてのサービスには攻撃対象がある。個々のサービスを理解した上で、許可ルールの中でそのサービスを許可すること
{
"Sid": "AllowBaselineServices",
"Effect": "Allow",
"Action":[
"billing:*",
"cloudtrail:*",
"cloudwatch:*",
"config:*",
"logs:*",
"guardduty:*",
"health;*",
....
],
"Resource": "*"
}上記ポリシーは、組織内のアカウントの種類に関係なく常に必要とされる基本サービスのセットを定義したポリシーである。
UC3:We use SCP to deny exfiltration
{
"Sid": "DenyS3writesToUnauthorizeBuckets",
"Effect": "Deny",
"Action":[
"s3:Put*"
],
"Resource": "*",
"Condition":{
"StringNotEquals":{
"aws:ResourceOrgID":"o-xxxxx"
}
}
}VPC内から個人用S3バケットにデータをアップロードするためのブロックパス
データ流出に関するユースケースである。AWSの組織に属さないデータソースへのデータアップロードを拒否するために、"aws:ResourceOrgID"キーを利用する。このユースケースの具体的な実装の1つは、私たちの組織に属さないS3バケットへのアップロードを拒否することである。
UC4:Our guardrail policy attachments are immutable
- What is immutable - Build once, attach forever
- ガードレールSCPはRootに恒久適用する
- 拒否ルール(Deny rules)は、組織全体のアクションを防止する。例外はない。
- 制限ルール(Strict rules)は、特定OUのアクションを制限するもの
- 条件キー "aws:PrincipalOrgPaths "を使用する
- 制限を除外するためには、SCPを切り離したり、SCPを変更したりする必要はなく、その制限を除外しているOUにアカウントを移動させる。OUのメンバーシップをルールに基づいて監視する。
OUメンバーシップを通じてSCPコントロールの変更に影響を与えることで、ポリシーアタッチメントを変更できないようにしながら柔軟性を持たせることができる。
UC5:We Disable all actions for Lock Ou
{
"Sid": "Lock",
"Effect": "Deny",
"Action":"*",
"Resource": "*",
"Condition":{
"ForAnyValue:StringEquals":{
"aws:PrincipalOrgPaths":[
"o-xxxxx/r-xx/",
"o-xxxxx/r-xxx/ou-xxx-xxxxxxx/"
]
}
}
}Conditionに指定しているのは、LockOUとRootのメンバーに対する拒否アクションで、アカウントに対するすべてのコントロールプレーンアクションを無効にする。
攻撃面を減らすということである。何百ものアカウントを扱う場合、アカウントに対するすべてのコントロールプレーンのアクションを無効にできる隔離場所が必要になる。例えば、廃止予定のアカウント、セキュリティ事故の調査のために隔離されたアカウント、すでに廃止され、その90日間に削除されるのを待っているアカウントなどである。アカウントをロックOUに移動させると、ガードレールSCPはアカウントに対するすべてのコントロールプレーンアクションを拒否するので、アカウントは実質的に麻痺状態になる。
ポリシー・ステートメントの"aws:PrincipalOrgPaths"に、RootのパスとLock OUのパスを記述している。ユーザーがルート直下にアカウントを作成することを抑制する。末尾のスラッシュに注目してほしい。この条件はサブOUのメンバーではなく、rootの直接のメンバーにのみ適用されることを意味する。
Morgan Stanley SCP best practices
5つのユースケースをご紹介した。最後にSCPに関して私たちが行っているベストプラクティスを紹介する。
- Deny Policies are out guardrails. Attach guardrails to org root level
- Allow Policies are our enclaves. Attach enclaves to leaf account level
- Security Monitoring to assure leaf accounts do not attach FUllAWSAccess, and operational monitoring to assure OUs always attach FullAWSAccess
- Separation of duty between managing organization versus the rest of the account
- Key organization artifacts are managed by DevSecOps pipeline, rest of AWS managed by DevOps pipeline
- Separation of entitlement between org management account and leaf accounts
- Every new service allowed in enclaves follows a security review
- OUs are our best friends for managing AWS account group restrictions
- Guardrail policy immutably attached to org root and denies actions based on OU membership (aws:PrincipalOrgPaths)
- Restrict Regions base on OUs
- Put the unneeded accounts in LOCK OU
- Only allow root login in a highly monitored OU
Resources
Blog:get more out of service control policies in a multi-account environment
Example service control policies to get started
Getting started with AWS Organizations
感想
AWSをどのように活用しているかという事例はいつも興味深い話が聞けていいなと思っているのですが、今回のモルガン・スタンレー社の事例はとても参考になりました。最後にこれが俺たちのベストプラクティスだ！って紹介しているのは素晴らしいですね。OrganizationsやSCPのより活用すべきヒントが得られました。re:inforce2022のレポートブログはこれが2本目で、1本目は箇条書きで書いたのですがスマホで見づらかったところが反省点でした。それを踏まえて深いレベルの箇条書きをなるべく無くしてみました。
2
