10歳の誕生日おめでとう – AWS Identity and Access Management

Amazon S3 は今年初めに 15 歳になりましたが、 Amazon EC2 も数か月後に同様になります。本日は、AWS Identity and Access Management (IAM) の 10 歳の誕生日を祝いたいと思います。

最初の 10 年
それでは過去 10 年をふり返り、最も重要な IAM の歴史を見ていきましょう。

2011 年 5 月 – IAM をリリース。ユーザー、ユーザーのグループを作成し、ポリシードキュメントをいずれかにアタッチする機能を備え、15 種類の AWS のサービスをサポートしていました。AWS Policy Generator を使用すると、ポリシーを最初から構築でき、事前定義されたポリシーテンプレートを適度に備えたコレクションもありました。このローンチにより、IAM の標準が定まり、アクションとリソースに対するきめ細かなアクセス許可、ポリシーを有効にするタイミングを制御する条件の使用が可能になりました。このモデルは AWS とともに拡張され、現在も IAM の中心的な役割を果たしています。

2011 年 8 月 – 短期間の一時的 AWS 認証情報のサポートなど、AWS アカウントにフェデレーションすることで既存の ID を使用できる機能を導入しました。

2012 年 6 月 – EC2 インスタンス向け IAM ロールの導入により、EC2 インスタンスで実行するコードが AWS のサービスを簡単に呼び出すことができるようになりました。

2015 年 2 月 – マネージドポリシーをリリースし、同時に既存の IAM ポリシーを、複数の IAM ユーザー、グループ、またはロールで作成、名前付け、使用できるファーストクラスのオブジェクトに変換しました。

2017 年 2 月 – AWS Organizations をリリースし、組織単位の階層にグループ化される、複数の AWS アカウントにまたがるポリシーベースの管理を実装する機能を提供しました。このリリースではまた、組織のアカウント内で許可されているアクセスレベルの周りにガードレールを配置する権限を与えるサービスコントロールポリシー (SCP) もデビューしました。

2017 年 4 月 – EC2 インスタンス向け IAM ロールに基づいて、サービスにリンクされたロールを導入しました。これにより、AWS のサービスにアクセス許可を委任できるようになり、代わりに他の AWS のサービスを呼び出す必要のある AWS のサービスを簡単に操作できるようになりました。

2017 年 12 月 – AWS アカウントやビジネスアプリケーションへのアクセスを一元管理しやすくするため、AWS Single Sign-On を導入しました。SSO は IAM の上に構築されており、ロール、一時的認証情報、およびその他の基本的な IAM 機能を利用しています。

2018 年 11 月 – 元のロールベースのアクセス制御を補完するものとして属性ベースのアクセスコントロール (ABAC) を導入し、さまざまなタイプのユーザー、リソース、および環境属性を使用して、ポリシーとアクセス許可の決定を推進できるようにしました。このリリースにより、IAM ユーザーとロールにタグを付け、ポリシー内の ID 属性とリソース属性を一致させることができるようになりました。このリリースの後、AWS SSO および Cognito と組み合わせた ABAC の使用のサポートを行いました。

2019 年 12 月 – IAM Access Analyzer を導入し、ポリシーの分析、パブリックまたは他のアカウントからアクセスできるリソースの決定をできるようにしました。

2021 年 3 月 – 実績のある AWS のベストプラクティスを活用する IAM ポリシーと SCP を構築できるように、IAM Access Analyzer にポリシーの検証 (100 を超えるポリシーチェック) と実用的な推奨事項を追加しました。

2021 年 4 月 – アクセスアクティビティに基づいて、最小特権の IAM ポリシーテンプレートを生成できるようにしました。

あの頃、そして今
初期の頃、一般的なお客様は IAM を使用して、少数の S3 バケット、EC2 インスタンス、およびSQS キューへのアクセスをすべて単一の AWS アカウントでコントロールしていました。最近では、一部のお客様は IAM を使用して、複数の AWS アカウントにまたがる数十億ものオブジェクトへのアクセスをコントロールしています。

AWS API を呼び出すたびに IAM を呼び出してアクセス許可を確認する必要があるため、IAM チームは最初から可用性とスケーラビリティに重点を置いています。2011 年に遡ると、「発信者はこれを実行できますか?」機能が 1 秒あたり数千のリクエストを処理しました。現在、新しいサービスが出現し続け、AWS の顧客ベースが増え続けるにつれて、この機能は現在、世界中で 1 秒あたり 4 億を超える API 呼び出しを処理しています。

この要約からわかるように、IAM は、わずか 10 年前のシンプルでありながら強力な始まりから、かなり長い道のりを歩んできました。10 年前に真実であったものの多くは現在も真実ですが、時間の経過とともに進化してきたいくつかのベストプラクティスに注目したいと思います。

複数のアカウント – もともと、お客様は一般的に 1 つの AWS アカウントと複数のユーザーを使用していました。現在、複数の事業単位とワークロードに対応するには、AWS Organizations と複数のアカウントを使用することをお勧めします。最初は AWS の使用方法が比較的シンプルで単純であっても、使用の規模や複雑さが増す可能性があるため、事前に計画しておくことをお勧めします。詳細については、AWS 環境のベストプラクティスの確立を参照してください。

ユーザーと SSO – 同様に、AWS SSO を使用してユーザーを一元的に作成および管理してから、1 つ以上の AWS アカウントへのアクセスをユーザーに許可することをお勧めします。詳細については、AWS Single Sign-On ユーザーガイドを参照してください。

お誕生日おめでとう、IAM
私たちの有名なカスタマーオブセッションに従って、いつものように皆様からのフィードバックをお待ちしています! 今後 10 年間でどのような IAM の新しい機能を見たいですか? コメントを残していただければ、チームが確認いたします。

それでは、10 歳の誕生日おめでとう、IAM!

– Jeff