属性ベースアクセス制御とは？属性からポリシーを導く

属性ベースアクセス制御 (ABAC) は、要求者、リソース、そして周囲のコンテキストの属性をポリシールールに照らして評価することで、アクセスを判断します。

属性ベースアクセス制御、すなわちABACは柔軟な認可モデルです。ユーザーを固定的なロールにマッピングするのではなく、ABACは属性に対するルールを評価します。誰が要求しているのか、何にアクセスしているのか、そして要求の条件は何かです。アクセスがコンテキストに依存する必要がある場合に真価を発揮し、これはクラウドやCI/CDのシステムでますます一般的になっています。

ABACはどう判断するか

ポリシーエンジンは「ユーザーの部署がリソースの所有者と一致し、かつ要求が信頼されたネットワークから来た場合に許可する」といったルールを評価します。入力は属性であり、出力は許可または拒否です。これにより、すべてのユーザーを列挙することなく、単一のポリシーで多くのケースをカバーできます。

属性のカテゴリ

サブジェクト属性: ロール、チーム、クリアランス。
リソース属性: 所有者、機密度、環境。
コンテキスト属性: 時刻、場所、要求元。

ABAC対RBAC

RBACはよりシンプルで監査しやすいですが、アクセスがコンテキストに依存する場合、多数の狭いロールへと膨れ上がることがあります。ABACはコンテキストをきれいに扱えますが、理解するのがより難しくなることがあります。多くの実システムはRBACから始め、きめ細かいケースのためにABACスタイルの条件を重ねます。

CI/CDにおけるABAC

クラウドの信頼ポリシーはしばしば属性条件を使用します。パイプラインは、OIDCトークンの属性が特定のリポジトリ、ブランチ、環境を示す場合にのみロールを引き受けられます。これは実践におけるABACであり、静的なロールだけでなく、ワークロードのアイデンティティに基づいてアクセスを制限します。

強みとトレードオフ

ABACは複雑なルールへとスケールし、ロールの氾濫を減らしますが、ポリシーは不透明でテストしにくくなることがあります。明確なポリシーの記述、テスト、レビューが不可欠であり、そうでなければ微妙なルールが意図以上の権限を付与してしまう可能性があります。

ABACとエフェメラルなrunner

パイプラインのOIDCトークンはjobに関する属性を持つため、ABACの条件はアクセスをまさにそのコンテキストに固定できます。エフェメラルなrunner (Latchkeyのマネージドrunnerなど) では、属性は単一の短命なjobを記述するため、ポリシーによって付与されたアクセスはそれとともに失効します。

重要なポイント

ABACはサブジェクト、リソース、コンテキストの属性をポリシールールに照らして評価します。
コンテキスト依存のアクセスをRBACより上手く扱えますが、監査はより難しくなります。
クラウドのOIDC信頼ポリシーは、パイプラインのアクセスを絞り込むためにABACスタイルの条件を使用します。