Amazon Web Services ブログ
新しい ID フェデレーション – AWS でアクセスコントロールに従業員属性を使用する
AWS または他の多くのシステムのリソースへのアクセスを管理する場合、ほとんどの場合、ロールベースのアクセスコントロール (RBAC) を使用するでしょう。RBAC を使用する場合、リソースへのアクセス許可の定義、こうしたアクセス許可のポリシーによるグループ化、ポリシーのロールへの割り当て、個人、個人のグループ、サーバー、アプリケーションなどのエンティティへのロールの割り当てを行うことになります。多くの AWS のお客様は、組織内で同様のビジネス機能を共有している人などの関連するエンティティへのアクセス許可の付与を簡素化するためにそうしていると語っています。
たとえば、財務データベース管理者のロールを作成し、そのロールに財務に必要なテーブルやコンピューティングリソースへのアクセス権を付与することができます。データベース管理者の Alice がその部門に移動すると、彼女に財務データベース管理者のロールを割り当てます。
AWS では、AWS Identity and Access Management (IAM) のアクセス許可ポリシーおよび IAM ロールを使用して、RBAC 戦略を実装します。
リソースの増加により、スケーリングが困難になります。新しいリソースがシステムに追加されると、システム管理者は、その新しいリソースに対するアクセス許可をすべての関連するポリシーに追加する必要があります。何千ものリソースや数千のポリシーがある場合、これをどのように拡張すればよいでしょうか? 1 つのポリシーの変更がユーザーまたはアプリケーションに不要な特権を付与しないことをどのように確認すればよいでしょうか?
属性ベースのアクセスコントロール
リソースが増え続ける状況の中、アクセス許可の管理を簡素化する新しいパラダイムが登場しました。属性ベースのアクセスコントロール (ABAC) です。ABAC を使用する場合、一致する属性に基づいてアクセス許可を定義します。ポリシーでは、ユーザー属性、リソース属性、環境属性など、あらゆるタイプの属性を使用できます。ポリシーは IF … THEN ルールになります。たとえば、 IF ユーザー属性 role
== manager
THEN 彼女は属性 sensitivity
== confidential
であるファイルリソースにアクセスできます。
ABAC アクセス許可コントロールを使用すると、リソースを追加するときにポリシーを更新する必要がなくなるため、アクセス許可システムの拡張が簡単になります。代わりに、リソースに適切な属性がアタッチされていることを保証する必要があります。ABAC では、ジョブロールごとにポリシーを作成する必要がないため、管理するポリシーの数を減らすことができます。
AWS では、属性はタグと呼ばれます。タグは Amazon Elastic Compute Cloud (EC2) インスタンス、Amazon Elastic Block Store (EBS) ボリューム、 AWS Identity and Access Management (IAM) ユーザーなどの様々なリソースにアタッチできます。リソースにタグ付けできることと、タグでアクセス許可の条件を定義できることを組み合わせると、ABAC パラダイムを採用して AWS リソースへのアクセスを効果的にコントロールできます。
AWS で ABAC アクセス許可を使用する方法の詳細については、ドキュメントの新しい ABAC セクションを読むか、チュートリアルを受講するか、re:Inforce で Brigid のセッションをご覧ください。
これは大きなステップでしたが、機能したのはユーザー属性が AWS に保存されている場合だけでした。多くの AWS のお客様は、別のソースで ID (およびその属性) を管理し、フェデレーションを使用してユーザーの AWS アクセスを管理しています。
フェデレーテッドユーザーの属性を渡す
ユーザーが標準ベースの SAML を使用して AWS にフェデレートするときに、AWS セッションでユーザー属性を渡すことができるようになりました。これで、AWS 内の属性ベースのアクセスコントロール決定の一部として、外部 ID システムで定義された属性を使用できるようになりました。外部 ID システムの管理者が、ユーザー属性を管理し、フェデレーション中に渡す属性を定義します。渡す属性は「セッションタグ」と呼ばれます。セッションタグは、フェデレーションセッションの期間中だけ有効である一時的なタグです。
ABAC を使用してクラウドリソースへのアクセスを付与すると、いくつかの利点があります。そのうちの 1 つは、管理するロールが少ないことです。たとえば、Bob と Alice が同じ職務を共有しているが、コストセンターが異なる状況を想像してみましょう。各個人のコストセンターに属しているリソースにだけアクセスを付与する必要があります。RBAC で 2 つのロールが必要であるのに対して、ABAC で必要なロールは 1 つだけです。Alice と Bob は同じロールを引き受けます。ポリシーは、コストセンタータグ値がリソースのコストセンタータグ値と一致するリソースへのアクセスを許可します。それでは、20 のコストセンターに 1,000 人を超える人がいると想像してみましょう。ABAC は、コストセンターのロールを 20 から 1 に削減できます。
別の例も考えてみましょう。開発者が IAM ロールを使用して AWS にフェデレートするときに、システムエンジニアが CostCenter
をセッションタグとして含めるように外部 ID システムを設定するとします。すべてのフェデレーション開発者は同じロールを引き受けますが、アクセス許可はフェデレーションセッションに含まれる CostCenter
タグとリソースに基づいて適用されるため、コストセンターに属する AWS リソースへのアクセスだけが付与されます。
この例を次の図で説明します。
上の図で、青色、黄色、緑色は、従業員ユーザーがアタッチされている 3 つのコストセンターを表しています。ABAC を設定するには、まずすべてのプロジェクトリソースにそれぞれの CostCenter
タグをタグ付けし、開発者セッションに CostCenter
タグを含めるように外部 ID システムを設定します。このシナリオの IAM ロールは、CostCenter
タグに基づいてプロジェクトリソースへのアクセスを付与します。IAM アクセス許可は次のようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [ "ec2:DescribeInstances"],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["ec2:StartInstances","ec2:StopInstances"],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"
}
}
}
]
}
条件が一致した場合のみアクセスが許可 (付与) されます。つまり、リソースの CostCenter
タグの値がプリンシパルの CostCenter
タグの値と一致した場合です。ここで、従業員ユーザーがこのロールを使用して AWS にフェデレートする場合は常に、フェデレーションセッションに含まれる CostCenter
タグに基づいて、コストセンターに属するリソースにだけアクセスできます。
ユーザーがコストセンターを緑色から青色に切り替えると、システム管理者は外部 ID システムをCostCenter
= 青色
で更新し、AWS のアクセス許可が自動的に適用され、AWS でのアクセス許可の更新を必要とせずに、 青色コストセンターの AWS リソースへのアクセスを付与します。同様に、システム管理者が外部 ID システムに新しい従業員ユーザーを追加すると、このユーザーはすぐに自分のコストセンターに属する AWS リソースにアクセスできます。
私たちは Auth0、ForgeRock、IBM、Okta、OneLogin、Ping Identity、および RSA と連携して、彼らのシステムで定義された属性が AWS セッションに正しく伝播されるようにしました。詳細については、AWS のセッションタグの設定に関する公開ガイドラインを参照してください。他の ID プロバイダーを使用している場合でも、業界標準の SAML 2.0 または OpenID Connect (OIDC) をサポートしていれば、セッションタグを設定できる場合があります。さらに多くの ID プロバイダーと協力して、彼らの IDソリューションでセッションタグを認証できることを楽しみにしています。
セッションタグは、今すぐ、すべての AWS リージョンで追加料金なしで利用できます。新しいセッションタグのドキュメントページを読んで、ステップバイステップの手順に従って ABAC ベースのアクセス許可システムを設定することができます。