こんにちは、SCSKの 網中です。
今回はざっくりとAWSのアカウントの権限設計をする上で必要となるの基本知識と、ポリシーの書き方を記載しようと思います。
なお、IAMについての概要を知りたい方は、前回の記事を読んでから本記事を読んでいただけますと幸いです。
はじめに
さて、先日はIAMポリシーについての記事を書きましたが、AWSの権限管理で知っておくべき項目は他にも多数あります。
例えば、S3でファイルにアクセスするユーザを制限したいといった場合は、S3のバケットポリシー・ACLで管理しますし、サービスの暗号化で良く利用されるKMSでは、それぞれどのユーザ・サービスがそのキーを利用できるのかキーポリシーで権限を管理する必要があります。または、OrganizationsのSCPでアカウント毎に権限管理を行うなどなど…AWSの権限管理は、奥深いものになっております。
そこで、AWSの権限管理する上で知っておくべき情報をギュギュっとまとめてみました！
AWSの権限管理の基本①：明示的許可・暗黙的拒否・明示的拒否
AWSの権限管理での基本の基本となるのが、明示的許可・暗黙的拒否・明示的拒否の考え方です。
簡単にまとめると下のような感じです。
- ポリシーにとある操作を許可するステートメントに記載すること → 明示的許可
- ポリシーに明示的許可していない項目は、自動的に拒否すること → 暗黙的拒否
- ポリシーでとある操作を拒否するステートメントに記載すること → 明示的拒否
実際に手を動かしてみた方がこの辺りは分かりやすい為、頭の片隅に入れつつ読み進めていただければなと思います！
ちなみに、明示的許可を基本的に利用していく方針を「ホワイトリスト形式で管理する」といったり、明示的拒否で制限をかけていく方針を「ブラックリスト形式で管理する」と言ったりします。どういった権限管理の方針で進めていこうか考えたときに必ず考えることになるかと思いますので、下記のメリットデメリットをご参考にしていただけると幸いです。
| 方式 | 特徴 | メリット | デメリット | 適合するユースケース |
|---|---|---|---|---|
| ホワイトリスト | 明示的許可でポリシーを記述。記述のない権限は暗黙的拒否により利用できない。 | ・権限の範囲を絞れるため、セキュリティを高く保てる。 | ・ユーザの利用希望に応じてホワイトリストの編集が必要であるため運用負荷が高い。 | ・利用したサービスが決まっている環境。 ・利用サービスは申請・許可制にしたい場合。 |
| ブラックリスト | 許可しない権限を記述。記述のない権限は利用できる。 | ・統制を最小限にとどめて、ユーザに高い自由度を提供できる。 | ・新たにリリースされたサービスの利用統制が実質出来ない ・AWSはサービス数が膨大であるため、禁止したい権限が多い場合には不向き。 |
・検証、開発環境 ・Administrator / root |
| ハイブリッド | ホワイトリストとブラックリストを併用する。広めにホワイトリストで権限付与し、一部制約を掛けたい場合などで利用。 | ・条件付きで権限の許可・拒否の設定ができ、ポリシーを柔軟かつシンプルに保てる。 | ・特になし | ・上記全て |
AWSの権限管理の基本②：ポリシーの評価論理の3要素
AWSでは上記の明示的許可・暗黙的拒否・明示的拒否だけでなく、AWSの操作権限を決定する要素として以下の6つの要素があります。
ID ベースのポリシー
- リソースベースのポリシー
- IAM アクセス許可の境界
- AWS Organizations サービスコントロールポリシー (SCP)
- セッションポリシー
- ACL
ただし全ての要素をフル活用して管理しようとした場合、頭が混乱してしまいますので、今回は個人的にまず押さえておくべきと考える3つをご紹介します。もっと詳細を知りたい！という方はAWS公式ページをご参照ください。
① ID ベースのポリシー
IAMユーザやロールで実行できる操作を定義します。
② ソースベースのポリシー
ポリシーがアタッチされているリソースに対してプリンシパルが実行できる操作を定義します。
例）S3のバケットポリシー、KMSのキーポリシー
③ AWS Organizations サービスコントロールポリシー (SCP)
Organizations SCP は、組織または組織単位 (OU) のアクセス許可の上限を定義します。AWSアカウントの最低限使わせたくない範囲（ガードレール）を定義するポリシーと覚えておくと分かりやすいです。
AWSの権限管理の基本③：各ポリシーの構造
3つも6つもあるってどういうこと？と思う方もいらっしゃるかと思うので、AWSのポリシーの構造イメージを図にしてみました！
あくまでもイメージですので、本格的に設計していくような段階になりましたら、公式ページをご一読することをお勧めします。
まずはじめは、何の権限も付与されていない際のイメージ図で、グレーの暗示的拒否で全ての権限が閉ざしている状況です。
どこも穴があいていないのでAWSのどのサービスも操作できません。
次に、サービスコントロールポリシーのみとある権限を許可してみます。
しかしながら、IDベースのポリシーで許可していない為、どのAWSサービスも利用できません。
それぞれのレイヤーに穴をあける(明示的許可を追加する)ことでその直下のサービスを利用できるようになります。
但し、S3とEC2の真上にはまだグレーの層が残っている為、S3とEC2は操作できません。
そこで、それぞれの上の部分に穴をあける(明示的許可を追加する)ことでそれぞれの操作ができるようになります。
ただ、3レイヤーとも操作するとなると大変ですよね…
そこで、よくあるポリシーを設計のイメージ図が下記のような感じになります。
サービスコントロールポリシーで、最低限操作させたくないサービス・リソースを制限して、IDベースのポリシー・ソースベースのポリシーでより詳細な要件を詰めていく方針が分かりやすいかと思います。
ちなみに、海苔みたいな四角は、明示的な拒否を表してます。例えば、IAMの権限を付与したいけど、ユーザ作成だけは許可したくないといったような要望がある際は、一旦IAMの全権限を許可してから、IAM:CreateUserのみ明示的に拒否するといったことが可能です。
AWSの権限管理の基本④：ポリシーの書き方
さて、AWSの権限管理の構造まで理解できたところで、次はIDベースのポリシーの代表「IAMポリシー」の書き方についてご紹介いたします。
IAMポリシーを利用する場合、基本的にはAWSで用意されているAWS管理ポリシーで事足りますが、いろんなシステムが列挙して、部署ごとで使えるリソースの切り分けをしたいなどの要件が出てくるとどうしてもポリシーの作り込みが必要になってきます。
とは言え、IAMポリシーで設計する場面ももちろんありますので、この際IAMポリシーの書き方をマスターしてしまいましょう。
では、まず初めにAWS管理ポリシーの一つ「AmazonGuardDutyFullAccess」の中身をを見てみましょう。jsonを見慣れている方は、なんとなくわかるかもしれませんが、今回は余談も挟みつつひとつひとつ解説していきます。
① Effect ※必須
ここでは、「Allow」か「Deny」を選択することができます。
つまり、その｛｝内(ステートメント)の結果を許可するのか・拒否するのかを指定する項目になります。
② Action ※必須
ここでは、AWSのどのサービスのどんな操作を許可(又は拒否)するのかを記載します。
ワイルドカード（*）を使うとこで、それ以下全ての要素を含むことができます。
例）guardduty:* →GuardDutyの全ての操作を許可(又は拒否)する。
organizations:Describe* → OrganizationsのDescribe～といった操作をすべて許可(又は拒否)する
ちなみに、「Action」を「NotAction」を記載することで、指定した以外のサービス・アクションを許可(又は拒否)することができます。
Actionについては、気を付けていただきたい事項が2点あります。
注意事項（1）他のサービスに依存する操作がある
まずは、特定のサービスを利用する上で、それ以外のサービスの権限開放も必要となる点です。
上記のポリシーは「AmazonGuardDutyFullAccess」という事で、Guarddutyを利用する上で必要な権限が全て揃っているポリシーとなります。
その中にGuarddutyのフルアクセス権限（guardduty:*）だけでなく、IAMのサービスロール作成権限（iam:CreateServiceLinkedRole）やOrganizationsの権限が入っています。なぜ、それらが追加されているかというと、それらがないと利用できないGuardDutyの機能がある為です。GuardDutyがAWSアカウントとワークロードをモニタリングする上で、IAMロールにスイッチロールして各ログを参照するような動作をする為、GuardDuty用のロールを作る権限を付与必要があるのです。
特にIAMは曲者で、サービスを利用するタイミングで特定のRoleを自動的に作成していたりスイッチロールしてサービスが動いていたり、操作元の権限を利用して各リソースを操作したりなど思いのほかIAM権限が必要になる場面が多いです。
また、別のサービスのDescribeの権限がないと動かなかったりなどなど・・・ですので、権限設計の際には必ず実際と同じレベルのテストをするようにしてください。
注意事項（2）ネットワーク関係の権限制限
もう一点は、AWSの仕様上EC2サービスの中にVPC操作に関わるアクションが含まれている点です。
従って、ネットワークを操作できないようにしたい要望があった場合「VPC:*」という設定ができず、EC2のアクションから地道に設定する必要があります。
例えば、「EC2:ModifyVPC*」「EC2:CreateVPC*」といったような具合です。
③ Resource ※必須
基本的には「*」で全てのリソースを許可することが多いですが、
特定のリソースのみ指定したい場合は下記のようにARNで指定することが可能です。
特定のリソースのみ許可(又は拒否)したい場合はここに記載します。
よくある要件としては、ログ集積用のS3バケットの操作を制限したりする際に指定したります。
“Resource”: “arn:aws:s3:::xxxxxxxxxxx”
また、下記のような形でリソースを指定することも可能です。
この指定方法は、自身のIAMのパスワード・認証情報のみ操作できるように設定したい場合に便利です。
“Resource”: “arn:aws:iam::*:user/${aws:username}”
ちなみに、「Resource」を「NotResource」を記載することで、指定した以外のリソースを許可(又は拒否)することができます。
④ Condition ※任意
ここでは、特定の条件で操作を許可(又は拒否)したい場合によく使います。
例えば、特定のタグが付いたリソースのみ操作を許可したい・特定のユーザーにのみ操作を許可したいなどといった
場合によく使われます。
ここについては、書き出すと止まらなくなる為、下によく使うConditionについてピックアップしたものを記載致します。
詳細については知りたい方は以下ページをご参照ください。
よく使うCondition5選
1) 特別なタグが付いている際に権限が適用される場合の書き方
"Condition": {"StringEquals": {"aws:ResourceTag/Env":["Development","Product"]}}
※意味：キー名：Env、値Development又はProductタグが付いていた場合
2) 特別なタグ付いていない際に権限が適用されるの書き方
"Condition": {"StringNotEquals": {"aws:ResourceTag/Env":["Development","Product"]}}
※意味：キー名：Env、値Development又はProductタグが付いていない場合
3) 特定のロール・ユーザーにのみ権限が適用される場合の書き方
"Condition": {"StringLike": {"aws:PrincipalArn": ["arn:aws:iam::*:role/xxxxxxxxx","arn:aws:iam::*:user/xxxxxxxxx"]}}
※意味：操作元のリソースのARNが指定のARNであった場合
4) MFAが適用されている際に権限が適用される場合の書き方
"Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "True"}}
※意味：MFAがTrue（適用されてる）の場合
5) 特定のIP以外からの操作を制限する場合
"Condition": {"NotIpAddress": {"aws:SourceIp": "xxxxxxxxx"}}
※意味：操作元のIPアドレスが指定のIPアドレスではなかった場合
最後に
盛りだくさんの内容となってしまいました。
少しとっつきにくいAWSの権限設計ではありますが、ガバナンス強化のために必須になるところではありますので、AWSを利用し始めた方・これからアカウントのガバナンス強化を行いたい方のお役に立てましたら、幸いです。
もし、AWSの権限管理でこんなこと知りたいなどリクエストがありましたら、ぜひコメントをください！！