いまさら聞けないIAMのお話し その②
投稿日: 2025/09/22
はじめに
こんにちは、園田です。
「いまさら聞けないIAMのお話し その② 」になります。
途中からになりますので（１）を読んでない方は、まずは「いまさら聞けないIAMのお話し その①」を検索してみてください。
前回の続きという事で、まずは前回の振り返りから始めましょう。
前回はこんな感じでした。
- そもそもIAMってなに？
→ IAMっていつ使うの？ どんな種類があるの？ - IAMの基本要素
→ IAMユーザ、IAMグループ、IAMポリシー、IAMロールについて簡単にお話ししました。 - IAMポリシーについて（詳細）
→ IAMポリシーを作成する際の注意点についてお話ししました。 - IAMポリシーの注意点
→ IAMポリシーを利用する際の注意点（優先順位、conditionの条件）についてお話ししました。
今回はこんな感じのお話です。
- IAMに対するセキュリティ強化
- IAMロール詳細
- IAMロールの信頼
- IAMに関する統制
- Permission Boundary
- SCP（サービスコントロールポリシー）
今回も長くなりそうですね。
頑張っていきましょう。
IAMのセキュリティ強化したいんですけどー
いきなり、最初にお話しすると言っていた内容とタイトルが違いますが、気にせず行きましょう。
IAMのセキュリティ強化についてのお話です。
IAMを乗っ取られると大変ですからね。セキュリティは最重要で考えたいところです。
１．rootユーザのセキュリティ強化
IAMと言っておきながら、まずはrootユーザです。
AWSのアカウント開設時に利用するユーザ（メールアドレス）ですね。
こちらについてはセキュリティの強化の方法が以下３つしかありません。
- MFAを設定する
- SCPでrootを使えないようにする
- Root access managementでパスワードを削除する
1つずつ説明しましょう。
まずは、「A．MFAを設定する」ですね。
rootユーザに対し、MFAデバイスの設定をします。
有名なのは「Google Authenticator」とか、「Microsoft Authenticator」ですね。
「Microsoft Authenticator」は社用携帯にもインストールされているという方も多いのではないでしょうか。
これを使ってユーザID・パスワード + ワンタイムを実現します。
詳細はこの辺参照
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/enable-virt-mfa-for-root.html
スマホがあればセキュリティ強化が出来ると言っても、MFAの運用は数が多くなると大変です。かつ、スマホの場合、誰のスマホに設定するの？という問題が発生します。
という訳で、最近はB、Cが主流になります。（実際には色々（契約上の）制約があって出来ない場合も多いですが。）
「B．SCPでrootを使えないようにする」ですが、こちらはSCPにてrootをＤenyする形です。organizationを利用して、control towerを有効にするとデフォルトで設定されるSCPでrootがDenyされます。
どうしてもrootを利用したいという場合、SCPが適用されているOUとは別のOUに対象アカウントを移動させてからrootを利用するという方法です。
そこまで手間はかかりませんが、そもそも「Organization利用が前提」、「SCPで設定が必要」、「オペレーションでOUを移動させる必要がある」というのがネックです。
最後は「C．access managementでパスワードを削除する」になります。
こちらもOrganizationの利用が前提となりますが、「Root access management」というサービスでrootのパスワードを削除することで実質使えない状態となります。
必要なときは都度パスワードを設定して使い終わったら元に戻す形です。
こっちもオペレーション必要じゃん、という話ですが、SCPで制御するより専用ツールである分お手軽です。（SCPはrootの制限にも使える、というものなので）
ということでrootユーザのセキュリティ強化はこんなところですね。
後、当たり前ですが、rootユーザのアクセスキー・シークレットキーの発行は絶対にやめてください。（まぁ、ITの世界においてデフォルトのAdministrator権限を持つユーザを利用しないのは一般常識なので、大丈夫だとは思いますが…）
２．IAMユーザのセキュリティ強化
IAMユーザのセキュリティ強化ですが、まぁ大体こんな感じです。
- 「A．MFAを設定する」
- 「D．必要な権限のみに絞る」
- 「E．IP制限を実施する」
- 「F．IAMユーザを使わない」
「A．MFAを設定する」はrootユーザと一緒です。
「D．必要な権限のみに絞る」
こちらについてはAWSのベストプラクティスにも記載されています。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html
とはいえ、あんまり絞りすぎると運用が大変になってしまうので、アカウントを本番・検証・テストなどに分けてアカウント別で権限を分ける方が現実的だとは思います。
なお、「IAMロール」の所で説明しますが、スイッチロールするためにSTS権限だけをIAMユーザに付与するというのは大変良い設計とは思います。
その場合の権限はこんな感じですね。
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::235494806643:role/xxxxxx",
"arn:aws:iam::235494806643:role/xxxxxx"
]
}
}
「E．IP制限を実施する」
こちらは「いまさら聞けないIAMのお話し その①」にて
「■特定のIPからのみ操作を可能とするIAMポリシー」の所で記載していますので見てみてください。
本ポリシーは「指定したIP以外からだと全ての権限をDenyする」という事で、セキュリティを担保します。
が、これ以外と欠点があって、AWSの場合、特定の操作をしようとした際に、サービスからサービスを呼び出すという動きをする場合があります。
この制限をかけていると「サービスからサービスを呼び出す」際のサービスのIPが指定したIPではないため、操作が実施できない場合があります。
「サービスからサービスを呼び出す」操作について明言されていればまだ救いようがありますが、AWSからは情報が公開されていません。
そのため、IPアドレス制限を掛けるというのはお勧めできません。
もちろん、STS権限だけを付与して、スイッチロールできる前のIPを制限するというやり方を利用するのであれば全く問題ありません。
その場合は、むしろ推奨します。
「F．IAMユーザを使わない」
IAMユーザを利用せず、外部認証ソース（Entra ID（旧Azure AD）など）で認証を行い、フェデレーションを実施する案ですね。
IAMロールの所で詳細を記載したいと思います。
IAMロールについて詳しく教えてください
次はIAMロールのお話になります。
IAMロールはこんな感じで「帽子」のアイコンになっています。
AWSのアイコンが新しくなってから、アイコンの画像から何を意味するのか良く分からないものが多くなりましたが、IAMロールに関しては非常に意味をあらわしているいいアイコンですね。
みての通り、IAMロールは「帽子」になっているため、帽子を機能させるために「何かが帽子をかぶる」必要があります。
この帽子を被るのが
- IAMユーザ
- AWSのインスタンス
- 外部認証ソース（Entra ID（旧Azure AD）など）で認証したユーザ
となります。
なので、
- sts権限のみを保持するIAMユーザがスイッチロールして、ロールに割与えられた権限で操作を実施する。
- EC2のサーバにAdministrator権限を持つロールをアタッチして、対象EC2から全ての操作を実施する。
などの対応が可能となります。
なお、IAMロールはあくまで「帽子」なので、例えばスイッチロールを実施したユーザがEC2を削除した場合、CloudTrailにはIAMロールではなく、IAMユーザとしてログが残ります。
そのため、IAMロールを複数のユーザで利用した場合も、誰が実施したかというのは確実にログが残りますので安心です。
IAMロールにおける信頼とは
帽子を「被れる」、「被れない」を定義しているものが「信頼関係」になります。
具体的に言うとこんな感じですね。
上記は「EC2」と「S3」がこのロールから信頼されており、利用することが出来ます。
IAMロールを作成する際に「信頼されたエンティティタイプ」を選択する画面があり、そこでEC2とかを選択したりしますがEC2を選択すると、この信頼関係にて以下のように記載されるだけ、という事です。
"Principal": {
"Service": "ec2.amazonaws.com"
}
信頼関係の記載方法はIAMユーザからスイッチロールする際も変わりはありません。
スイッチロールの信頼関係はこんな感じですね。
上記はロールから信頼する形になっていますが、ユーザから信頼する場合は、userとなります。
混在させる場合はこんな感じですね。
"AWS": [
"arn:aws:iam::アカウントID:user/xxxxxx",
"arn:aws:iam::アカウントID:role/xxxxxx"
]
},
「user」がIAMユーザで、「role」がIAMロールになります。
このやり方はAWS以外のレポジトリ（Entra ID（旧AzureAD））にて認証（フェデレーション）させる場合でも一緒です。
Entra IDで認証したものを信頼させる場合は、信頼関係に以下のように記載します。（※）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/microsoft-entra-id"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": https://signin.aws.amazon.com/saml
}
}
}
]
}
■Entra ID（旧Azure AD）で認証させる場合のやり方はこちら
https://learn.microsoft.com/ja-jp/entra/identity/saas-apps/amazon-web-service-tutorial
※実際の信頼関係は手順に基づいて実施すると勝手に記載されます。
また、実際にはこれ以外にも証明書を入れたりという作業が必要になります。
詳細は上記のURLを参照ください。
基本、信頼はAWS内であれば、自分のアカウント・他のアカウントを問わず信頼関係を簡単に記載することが出来ます。
管理するアカウント多くて、という場合は作業対象アカウントにて、中央アカウントのロールなどを信頼する対応を実施し、全てアカウントを同じ操作にて実行できる形にするのが良いでしょう。
（やはりこの辺はマルチクラウドだとちょっと大変になってしまいますね。）
なお、複数AWSアカウントが存在する場合のIAM管理については「Entra ID等を利用する」、「IAM Identity Centerを利用する」、「IAM用の管理用アカウントを作成する」などの方法があります。
最も簡易なのは「IAM用の管理用アカウントを作成する」ですかね。
別に専用でなくても良いので、「IAMユーザはこのアカウントに集約する。」というルールを定義して、各アカウントには必ずスイッチロールする形式をとればOKです。
（「言うは易く行うは難し」の典型のような気もしますが…）
「IAM用の管理用アカウントを作成する」場合の管理はこんな感じ
IAMに関する統制
最後はIAMに関する統制ですね。
基本的にIAMの権限というのは統制が非常に難しいです。
例えば、セキュリティホールを作らない様、「通常ユーザにはIAM操作はさせたいけど、IAMユーザは作成させたくない」
などの要件が発生することがあります。
（IAMを操作できないと、AWSの操作が出来ないのでIAM権限は付与したいけど、特定の操作はさせたくない）
この場合、ユーザにはIAM権限を付与してしまうので、IAMユーザ作成をDenyの権限を付与していたとしても自分で外せてしまいます（IAMポリシーを外す権限があるので）。
まぁ、考えれば当たり前ですが、そもそも「権限を付与することが出来る権限を統制しよう」という話なので若干無理があります。
この若干無理がある要件をかなえる機能が、以下の2つになります。
- Permission Boundary
- SCP（サービスコントロールポリシー）
SCP（サービスコントロールポリシー）とは
こちらはOrganizationの機能となります。
そのため、リセラー等からAWSアカウントを払いだされている場合、利用できない場合があります。
この機能が使いたいという場合は、Organizationが利用できるかきちんと確認しましょう。
制限がある分、強力無比な機能となります。
（大体、漫画だと制限・制約がある能力の方が強いよね。）
SCPについてはこんな感じで利用します。
上記の図にあるポリシーがSCPになります。
例えば、IAMユーザの作成をさせたくないといった場合、以下のようなポリシーになります。
"Action": [
“iam:CreateUser”
],
"Effect": “Deny",
"Resource": [
*”
],
"Condition": {
"StringNotLike": {
"aws:PrincipalARN": [
"arn:aws:iam::*:role/xxxxxxxx",
"arn:aws:iam::*:user/xxxxxxxx",
"arn:aws:iam::*:root"
]
}
}
ここでのポイントはCondition句の「StringNotLike」で特定のユーザやロールからの操作を「除外」しているところです。
SCPは非常に強力で、「iam:CreateUser」をDenyしてしまうと全てのユーザやロール（rootユーザ含む）からIAMユーザの作成が実施できなくなってしまいます。
これはSCPがアカウントに対して動作する（厳密にはアカウント集めたOU）ものだからです。そのため、強制的にルールを守らせることが出来る。というのが最大のメリットです。（ここが後で説明するPermission Boundaryとの差異になります。）
まぁ、IAMユーザに関してはこれでも良いかもしれませんが、どうしても例外が発生することを考慮して特定の管理者からのみは除外するという設定を事前にしてあげる必要があります。
要するに運用を考慮しておけ、という事ですね。
これ以外はIAMポリシーと全く一緒です。
基本SCPはDenyで記載するIAMポリシーといっても問題ありません（※）。
※実際にはSCPだと記載出来ない記述が存在します。
ほぼ制約は無くなりましたが（SCPがリリースされた直後は結構あった）、利用時は必ずテストしてから利用しましょう。
Permission Boundaryとは
Organizationは使えないけど、頑張って統制をかけたいよー。という方はこのPermission Boundaryを使いましょう。
歴史的には、Permission Boundary→SCPの順番になります。 そのため、過去はPermission Boundaryを使っていたという方もいるのではないでしょうか。
Permission Boundaryを一言で表すとこんな感じです。（図ですけど）
AWSのマネジメントコンソール上だと、「許可の境界」という記載になっています。（日本語の場合）
見て貰えばわかりますが、
- IAMポリシーで許可
- Permission Boundaryで拒否
をすることにより、出来ることを制限する方式です。
基本SCPと一緒の感覚で利用することが出来ますが、SCPとは異なり全てのIAMユーザ、IAMロールにこのPermission Boundaryを設定する必要があります。
そのため、たとえば特定のロールに対し、Permission Boundaryを入れ忘れたという事があると途端に統制が瓦解してしまうという欠点があります。
そういう意味では基本的にはSCPの方が使い勝手が良いです。
そのため、Permission BoundaryはOrganizaitionが使えない場合のみ利用というのが良いかと思います。（ちなみにPermission BoundaryからSCPに変更はとても大変です。全てのユーザ、ロールからPermission Boundaryを削除しないといけないので）
正直なところ、Permission Boundaryを使っているお客様を見たことがありません。
AWSに相談しても多分SCPしか言われないでしょう。
たまにはPermission Boundaryの事も思い出して欲しいな。と思わなくもないです。
という訳で、「いまさら聞けないIAMのお話し その②」のお話でした。
IAMの話は書いていて疲れますね。多分、読まれた方もつかれたことでしょう。
（本当に、「いまさら聞けない」レベルの話だったのか、甚だ疑問な所です。かなり難しかったですよね。）
いまさらシリーズは今後も続けていきたいと思いますので、今後ともよろしくお願いいたします。頑張ります。
- 関連コラム
