AWS、AWS SSOとOktaによるエンドツーエンドのABAC構築の利点およびその方法を解説

　米Amazon Web Servicesは、属性ベースのアクセス制御（ABAC）戦略を使用する利点と、OktaをIDプロバイダ（IdP）として用いる際にAWS Single Sign-On（AWS SSO）でABACを使用する方法について、7月6日（現地時間）付の公式ブログ投稿にて解説している。

　同投稿では、ABACを使用する理由として、属性条件の一致に基づいてアクセスを提供する、より動的なポリシーの構築が可能になる点を挙げており、AWSでは共存戦略としてRBACとABACの両方をサポートしているため、既存のRBAC戦略と一緒にABACを使用できると、その利点を強調する。

　ABACを使用する利点としては、AWS Secrets Managerのシークレットへのアクセスを必要とする2つのチームが存在する状況で、ABACの使用によってIdPのDepartment属性に基づいた条件で、単一のロールまたはポリシーを構築する例を示している。同シナリオでは、ユーザーが認証されると、Department属性値を渡し、条件を使用して同じタグを持つリソースへのアクセスの提供が可能になる。

　さらに、組織においてABACを使用する利点として、

• 開発者が新しいプロジェクトリソースを作成する際に、管理者はリソースの作成時に特定の属性を適用するように要求できるため、開発者が自身の権限を更新することなく、作成した新しいリソースへ直ちにアクセス可能な属性を持つタグを適用できる
• 権限はIdPなどのコーポレートIDソースからのユーザー属性に基づいているため、AWSのアクセス制御に使用するIdPのユーザー属性を変更すると、AWSの権限が自動的に更新される
• ABACでは権限がユーザー属性に基づいているため、同じAWS SSO権限セットとIAMロールを使用している複数のユーザーが、引き続き一意の権限を取得可能であり、管理者は一致する属性を持つAWSリソースへのアクセスのみをユーザーに許可するIAMポリシーを作成でき、単一のAWSアカウントでさまざまなユースケースに作成する必要のあるIAMロールの数を減らせる
• IAMロールを使用してAWSで実行されるすべてのアクションに、AWS CloudTrailに記録されている属性を使用することで、セキュリティ管理者がロールセッションでアクションを実行するIDを簡単に判別可能となる

という、4点を挙げている。