LoginSignup
0
1

AWS IAM ポリシーの arn と Azure RBACのスコープの比較

Last updated at Posted at 2024-07-01

AWS の場合、IAM ポリシーで様々な認可制御を行います。

Azure をお使いの人だと、似たような概念は Azure Role-Based Access Control (Azure RBAC)だったりします。

Azure RBAC の場合も AWS IAM ポリシーの場合も、許可の対象を指定する必要がありますが、その指定するための文字列に「頭の切り替え」が必要だなと感じた話です。

Azure RBAC の対象(スコープ)指定

Azure RBAC の場合、Azure ポータルの アクセス制御 (IAM) という部分から、対象のリソースに対する認可が設定されたユーザー等が確認できます。

Azure の場合、下記のような階層構造があるので、上位の階層に設定された権限が下位の階層に継承されます。

  • (管理グループ)
    • サブスクリプション
      • リソースグループ
        • (リソース種別)
          • リソース

どの範囲に権限を設定するかの指定は「スコープ」と呼ばれ、こちらが AWS の arn に似た概念のように思います。

下記にスコープを文字列表現した形のよく分かる説明があります。

例えばリソースに対して権限を設定するなら、

/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/{providerName}/{resourceType}/{resourceSubType}/{resourceName}

という指定になるので、サブスクリプション > リソースグループ > リソース という階層構造を強く意識した構成をしています。

また、各階層に subscriptionsresourcegroups のような要素の説明が挟まるので、どの文字列が何を意味しているかが分かりやすいです。

AWS IAM ポリシーの対象(arn)指定

AWS IAM ポリシーで認可の対象を指定する場合は arn を記載します。

arn:partition:service:region:account-id:resource-id

partition の部分はほとんどのケースで aws なので、そこより右を Azure と比較してみると、特徴的なのは「サービス」が最初に登場することと、リージョンが登場することです。

強引に Azure の名称っぽく階層を書くと、

  • リソース種別(= AWS サービス)
    • リージョン
      • サブスクリプション ID(= AWS アカウント ID)
        • リソース ID

という形になりまして、Azure に慣れている私は頭が混乱してしまいます…

気を取り直して、AWS の arn の特徴としてワイルドカードを使えることが挙げられます。

例えば arn:aws:s3::: のように書くと、すべての S3 バケットへのアクセスを指定できます。

また別の良いところとして、例えば S3 の一部のフォルダだけに許可を与える arn も定義できます。

arn:aws:s3:::example-bucket/specific-folder/*

複雑になっていきますが、IAM ポリシーだけで様々な認可コントロールできるのが特徴的だと感じました。

具体的な IAM ポリシーの例を見てみましょう:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::example-bucket/specific-folder/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-bucket",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["specific-folder/*"]
        }
      }
    }
  ]
}

このポリシーは、example-bucketspecific-folder とその中身に対してのみ、オブジェクトの取得と追加を許可し、さらにそのフォルダ内のオブジェクトリストの取得も許可しています。

似たようなことを Azure Blob ストレージで実現する場合は、ストレージ BLOB データ共同作成者 等の BLOB に対する認可の権限をコンテナーまで絞ることができて、

/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/{providerName}/{resourceType}/{resourceSubType}/{resourceName}/blobServices/default/containers/{containerName}

のような形で指定することになります。
ただ、フォルダまでは指定できません。
(そもそも Azure の通常の Blob ストレージの場合、画面上は「フォルダー」と出ますが実態は Blob のプレフィックスでしかない)
2024/07/07追記: AWSの場合もフォルダはプレフィックスでしたので、上記は不要な記述でした。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/using-folders.html

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1