AWSのIAMユーザを社外に渡すことの問題点について

Question

静的webページが参照している特定のS3内の画像データを更新するツール/アプリを開発してほしいと依頼されました。
そこで、私はS3の特定のフォルダしかさわれないIAMユーザを発行して運用するのを提案しましたが、却下されてしまいました。

理由は、その画像データの更新は社外の方が行うので、会社のAWS環境にアクセスできるのはNGと言われてしまいました。

作成予定のアプリは当然、上記のIAMユーザと同権限のIAMロールをアタッチするので、IAMユーザとアプリのアカウント情報の流出の可能性と危険度は同じですと説明してもダメでした。社内ルールとのことです。

ここでようやく質問ですが、上記のようなIAMユーザを社外に発行することのリスクあるいはこの社内ルールの正当性についてお考えをお聞かせて頂きたいです。よろしくお願いします

Comments

[退会済みユーザー]

社内ルールなら従う以外の回答はないのでは。

[kujiraryo]

文が長くて申し訳ありません。質問内容は、IAMユーザを社外に発行することのリスクあるいはこの社内ルールの正当性についてお考えをお聞かせて頂きたいです。よろしくお願いします

Answer 1

作成予定のアプリは当然、上記のIAMユーザと同権限のIAMロールをアタッチするので、IAMユーザとアプリのアカウント情報の流出の可能性と危険度は同じですと説明してもダメでした。社内ルールとのことです。

正確なところは、社内ルール制定時に想定した「社内の事情、要件」を聞かないことにはわからないですが、ぱっと思いつく範囲でも以下のようなリスクや制限が存在します。

例えば、

• 権限設定にミスがあった場合、即致命的な問題につながる
• IAMユーザーの管理コストが向上し、結果として管理が行き届かない可能性がある

あたりは大きなリスクになり得ます。

S3クライアントに相当するものをを自力で作る場合、（アプリの作り方次第&脆弱性が無い前提ですが）アプリの作りによって実際に持っている権限よりも細かな権限の制御と通信の隠蔽が可能になりますので、
仮に権限設定をミスしたとしてもアプリ上で許可されている以上の操作を防ぐことが可能になります。

コストに関しては、IAMユーザーを管理している部門の人や知見が足りない場合、アプリ制作の単位でのIAMロール発行くらいであれば耐えられても、画像管理者が増減するたびにIAMユーザーを発行/停止するのは色々と大変で現実的には不可能というケースも多くあることでしょう。

このリスクは正しい知見を持った管理者が十分なリソースをあてて管理できるなら回避できるとは思いますが、組織の課題としてその前提がカバーできない場合は、不自由なルールによってカバーするしかありません。

また、機能面で言うと

• AWSのAPIやマネジメントコンソール、既存のS3クライアントに存在しない機能が必要になった場合に対応する方法が無くなる

という機能拡張性に関する制約もありますね。

これらに加えて、その組織独自の課題や制約などを加味した場合、外部の人間には思いもつかないようなリスクが発生するということは往々にしてあると思いますよ。