この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
IAM Access Analyzer が、対象リソースのパーミッション変更前の事前検証に対応しました！
これまでは変更後のリソースに対して自動的に分析を行う、という挙動でしたが、変更前のプレビューとしても確認ができるようになりました。
何が変わったのか
IAM Access Analyzer による分析を、対象リソースのパーミッション変更前のタイミングで実施できるようになりました。
対象が S3 バケットの場合、S3 コンソールから確認できます。
IAM Access Analyzer とは
IAM Access Analyzer は、 AWS リソースのリソースベースポリシーを参照し、外部エンティティからアクセス可能な状態になっていないかを確認できるサービスです。
「信頼ゾーン」と呼ばれるゾーンを定義し、その外部からのアクセスが可能な状態を確認すると、検知が行われます。
信頼ゾーンは多くの場合「自身の AWS アカウント」であり、Organizations と連携させた場合には「Organizations 全体」とすることもできます。
分析（スキャン、検証）対象としてサポートされている AWS リソースは以下です。
- S3 バケット
- IAM ロール
- KMS キー
- Lambda 関数とレイヤー
- SQS キュー
- Secrets Manager シークレット
詳細は以下を参照してください。
Using AWS IAM Access Analyzer - AWS Identity and Access Management
IAM Access Analyzer によるスキャンのタイミング
これまでは以下のタイミングでスキャンが可能でした。
- アナライザー作成時のすべての対象リソースに対するスキャン
- 定期スキャン（24時間以内の間隔）
- 手動での再スキャン（検知済みのリソースが対象）
- 検知済みのリソースの変更、もしくは新規リソースの作成をトリガーとするスキャン（30分以内。稀に例外あり）
いずれも、リソースのパーミッション変更後、つまりはすでに設定されているものに対するスキャンです。
比較的短時間で検出できるものの、誤って想定外の外部アクセス許可を与えてしまった場合、検出までは無防備な状態が続くことになります。
今回のアップデートにより事前の検証が可能となったため、きちんと変更による影響を理解した上でパーミッション変更を行えるようになりました。
IAM Access Analyzer による事前の検証
以下のパターンがサポートされています。
- S3 コンソールでの確認
- S3 バケットでのみ対応
- Access Analyzer API による確認
- 以下で対応
- S3 バケット
- IAM ロール
- KMS キー
- SQS キュー
- Secrets Manager シークレット
- 以下で対応
それぞれドキュメントはこちら。
- Previewing access in Amazon S3 console - AWS Identity and Access Management
- Previewing access with Access Analyzer APIs - AWS Identity and Access Management
後者の Access Analyzer API による確認では、以下 API を使用するとドキュメントに記載されています。
- CreateAccessPreview
- ListAccessPreviewFindings
新しい API がサポートされた際にはそれに対応する AWS CLI コマンドが追加されることが多いのですが、2021/3/11現在ではまだ確認できませんでした。
% aws --version
aws-cli/2.1.30 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off% aws accessanalyzer
apply-archive-rule delete-archive-rule get-finding list-findings untag-resource
create-analyzer get-analyzed-resource list-analyzed-resources list-tags-for-resource update-archive-rule
create-archive-rule get-analyzer list-analyzers start-resource-scan update-findings
delete-analyzer get-archive-rule list-archive-rules tag-resource参考にできる情報が少なかったので、本エントリではこちらのパターンを実際に試すのは見送ります。
やってみた（S3コンソールでのプレビュー）
S3 コンソールでバケットポリシーを変更する際にどのように変わったのか、確認してみます。なお、事前に Access Analyzer がセットアップ済みであることを前提とします。
バケットポリシーの変更画面から、以下のようなポリシーを入力してみます。
S3 バケットが存在する AWS アカウントとは別の番号を指定しており、クロスアカウントでのアクセス許可を与える内容です。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "s3:*",
"Effect": "Allow",
"Resource": "arn:aws:s3:::cm-chiba-hogehoge",
"Principal": {
"AWS": [
"000000000000"
]
}
}
]
}ポリシーの入力画面の下部に、新たに外部アクセスをプレビューという項目が追加されています。
[プレビュー] を押下します。
アナライザーによるスキャンが開始され、以下のように検出結果が表示されます。
外部プリンシパルに対してアクセス許可が与えられている、ということが分かります。（今回は「アクセスレベル」の項目が膨大な数にのぼったので、下部は省略します。）
プレビュー画面で確認できるのはここまでです。アクセスが意図した通りのものであれば、通常通りバケットポリシーの保存を実行しましょう。
外部アクセスを除外するパターン
上記のバケットポリシーを保存した後、再度バケットポリシーを修正します。
バケットポリシーを空にして再度「プレビュー」を実行すると、解決済みとして検出されました。
バケットポリシー変更による影響がどんなものかを理解するためにも、都度プレビューは実施したいですね。
パブリックを検知するパターン
以下のポリシーをセットして確認してみます。パブリックな読み書きを許可する設定なので、避けるべきものです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::cm-chiba-hogehoge"
}
]
}プレビューでは、「パブリック」というバッジがついて検出されます。
このバッジがついた時には、本当に公開して問題ないものかきちんと考慮しましょう。
ちなみにアナライザーはバケットポリシー以外の部分も評価してくれるため、ブロックパブリックアクセス（BPA）がオンになっていれば、上記のポリシーを入れたとしても検知されません。（バケットポリシーで許可しても BPA でブロックされるから）
S3 へのアクセスについて、きちんと考慮するきっかけになりますね。
終わりに
IAM Access Analyzer による事前検証がサポートされたというアップデートでした。
本エントリでは「新規」「解決済み」のパターンのみを取り上げましたが、「検出なし」というパターンもあります。
「バケットポリシーを変更するが、外部アクセスを許可する想定はない」という場合に、プレビューを実行してきちんと「検出なし」となるか、という確認も大事ですね。
手間はほとんど増えないので、バケットポリシー変更の際には毎度確認するのをおすすめします。
今回取り上げられなかったAccess Analyzer API による確認も、機会を見てチャレンジしたいと思います。
以上、千葉（幸）がお送りしました。
46
