AWS のアクセス虎の巻 IAM / SCPs / RCPs / 宣言型ポリシー

はじめに

AWS のアクセス制御というと、多くの方が利用しているのは IAM によるアクセス制御だと思います。

単一のプロジェクトのみの利用や、プロジェクト主体の AWS 運用では、IAM で十分な機能を有しています。
しかし、組織として AWS 運用を考えた場合、IAM だけでは不十分です。

IAM は、一般的にいうと『任意アクセス制御 (DAC)』という手法のアクセス権管理手法です。
アクセス管理の中には、『強制アクセス制御 (MAC)』という管理方法があります。

この記事では、アクセス管理手法としての DAC、MAC などを紹介し、その意義について簡単に触れたいと思います。
その後に、AWS でこれらを実現するための SCPs、 RCPs、そして宣言型ポリシーについて紹介します。

組織として、AWS アカウント管理を行う際の一助となれば幸いです。

アクセス管理手法

この章では、『任意アクセス制御 (DAC)』『強制アクセス制御 (MAC)』について紹介します。

この考え方自体は、AWS 環境に閉じず、汎用的なものですので、「こんな考えがあるんだ。」と、読んでください。

任意アクセス制御 (Discretionary Access Control)

任意アクセス制御 (DAC) とは広く普遍的で、多くの場所で活用されているアクセス制御です。

例えば、AWS の IAM、Linux の Permission、Windows の Access Control List (ACL) など、多くのシステムは任意アクセス制御となります。

これはシステムの管理者 (e.g. root / Administrator) が、他のユーザーやグループに対して、そのリソースへのアクセス権を自由に設定できる方式です。
簡単に実装でき、システムの連携が不要であることから、多くのシステムで利用されています。

しかし、組織として利用するには十分とは言えません。
システム管理者のミスや不正に対してのリスクに対して脆弱となってしまいます。

これらは、MAC により解決されます。

強制アクセス制御 (Mandatory Access Control)

強制アクセス制御は、システムの管理者による許可よりも、ポリシーの許可設定が優先・強制されるアクセス管理方法です。

AWS の SCPs や RCPs、Linux の SELinux などが強制アクセス制御を提供します。

管理者のミスや不正によりアクセス許可がされた場合でも、ポリシーで拒否されるリソースにアクセスすることはできません。

Linux では、Web サーバーは htdocs 配下のみアクセスを許可するなどの管理がされています。
これにより、マルウェア感染時であってもシステムを保護するような機能が提供されています。

DAC と MAC の比較

これらにより、DAC と MAC には以下のような差があります。

AWS のアクセス管理

IAM (Identity and Access Management)

IAM は、AWS で最も基本的なアクセス管理機能となります。

任意アクセス制御の一つであり、root ユーザーや、AdministratorAccess などの管理権限を持つ IAM user が、自身を含めた IAM user に対するアクセス権を管理できます。

IAM を利用した際の問題は、任意アクセス制御の問題とほぼほぼイコールとなります。
root ユーザー管理を委任したユーザーのミスや不正で AWS Account 全体が危険にさらされます。

また、組織の規定などを適用する責任は root ユーザーにあり、組織として管理を強制することはできません。

そのため、個人や小規模プロジェクトでは十分でも、組織の統制は効きません。

Permissions Boundary

IAM には Permissions Boundary という機能があります。

Permission Boundary は、そのユーザーのアクセス権の最大をポリシーとして定めるという点で強制アクセス制御 (MAC) であると考えられます。

Permission Boundary を用いることで、ユーザーは Policy で定める範囲内で権限を付与できることとなります。

例えば、Amazon S3 や CloudWatch のみにアクセスを許可する Policy がある場合、IAM 管理の権限を IAM で付与しても、その権限が有効になることはありません。

SCPs (Service Control Policies)

SCPs は、組織管理のアクセス制御として最初にリリースされました。

AWS は、組織で AWS 環境を保護する機能として AWS Organization を提供しています。
AWS Organization では OU (Organization Unit) という単位でユーザーや AWS Account を管理できます。

SCPs は OU 単位で、ユーザーのアクセスを強制することができます。
実施してはいけない操作を定義することで、ユーザーによる操作から、Service を保護する事が可能となります。

たとえば、請求管理者以外に Billing へのアクセスを拒否したり、本番 RDS に開発者アクセスを拒否することが可能となります。

この機能を活用することにより、root ユーザーによる誤った設定から AWS Account を保護することが可能となります。

RCPs (Resource control policies)

RCPs は、リソースに対するアクセスを強制する機能として 2024 年 11 月 13 日にリリースされました。

前述のとおり SCP が Service を保護するのに対し、RCPs が保護するのは Resource です。
Resource に対して追加のポリシーを適用することで、組織外ユーザーからのアクセスなどを禁止することが可能です。

そのため、現時点 (2025/01/06) でサポートされているリソースは、以下の 5 リソースのみです。

• Amazon S3
• AWS Security Token Service (STS)
• AWS Key Management Service (KMS)
• Amazon Simple Queue Service（SQS）
• AWS Secrets Manager

RCPs は、これらのリソースに対して OU (Organization Unit) 全体のアクセスを強制できます。

リソースコントロールポリシーの例 では、いくつかの例が示されています。

AWS では、STS として代理アクセスで他 AWS Account や組織にアクセスできます。
『混乱した代理問題』とは、この代理アクセスによりアクセスが組織内か組織外か分からなくなってしまう問題です。

これらの混乱した代理問題から Amazon S3 や Amazon SQS、AWS Secrets Manager を保護する例など、有用な例が提供されています。

これにより、データの所在地や、データのアクセス者など、データに対する管理を提供できるようになります。

宣言型ポリシー

宣言型ポリシー は、SCPs や RCPs とは異なり、現在・未来のリソースに対してベースライン保護として 2024 年 12 月 1 日にリリースされました。

AWS のリソースは膨大であり、生成 AI の Amazon Bedrock のような新しいサービスもどんどん提供されています。
SCPs や RCPs は現在のリソースを保護することは可能ですが、新しいサービスが出現した際にはポリシーの更新が必要となります。

宣言型ポリシーは、AWS::EC2::Subnet などの個々の具体的なリソースを扱いません。
現時点 (2025/01/06) では、以下のようなポリシーが設定できます。

• VPC Block Public Access
• Serial Console Access
• Image Block Public Access
• Allowed Images Settings
• Instance Metadata Defaults
• Snapshot Block Public Access

これらのポリシーを適用することで、包括的な保護を提供する事が可能です。

IAM、CSPs、RCPs、宣言型ポリシー

IAM は AWS Account の機能です。
SCPs、RCPs、宣言型ポリシーは AWS Organization の機能です。

機能としては、以下のような使い分けになります。

まとめ

組織として大規模な AWS Account 群を管理する場合、IAM だけでは難しいです。
大規模管理のために、AWS は AWS Organization の OU と連携した SCPs、RCPs、宣言型ポリシーを提供しています。

これらを活用することで、大規模なユーザーアクセス制御、大規模なリソース保護、ベースライン保護を提供できるようになります。

これらの機能には優劣はなく、それぞれの特徴を理解して組み合わせることが求められています。