Zenn
📌

AWS認定セキュリティ　IDおよびアクセス管理

2021/05/08に公開
AWS
tech

こんにちは！
AWS認定セキュリティ試験の勉強をしています。
今回は試験範囲の1つである IDおよびアクセス管理 の部分について勉強したことをまとめていきたいと思います。
基本的にはNRIネットコム株式会社の「要点整理から攻略する『AWS認定 セキュリティ-専門知識』」という本を使って勉強しております。とてもわかりやすいのでおすすめです。

目次

IAM
  • IAMロール
  • 職能機能の管理ポリシー
  • パーミッションバウンダリー(Permissions Boundary)
  • IAMアクセスアナライザー
Directory Service

Directory Service

Cognito

Cognito

Organizations

Organizations

IAM

「IDおよびアクセス管理」でも重点的に勉強した方が良いであろうIAMです。今回は以下4点についてまとめていきたいと思います。

  • IAMロール
  • 職能機能の管理ポリシー
  • パーミッションバウンダリー(Permissions Boundary)
  • IAMアクセスアナライザー

IAMロール

まずはIAMロールです。この3点の中では1番重要だと思っています。

何ができるの？

IAMロールを使うとAWSリソースや外部アカウントに一時的な利用権限を付与することができます。この利用権限の付与は AWS STS を利用し一時的認証情報を発行することにより実現しているそうです。

一時的認証情報って何なん？

と、思ったのですが読み進めていくとすぐに答えが見つかりました。わーい。

有効期限が短いアクセスキーとシークレットキー、セッショントークン

だそうです。

具体的にはどうやって利用権限を付与するの？

以下のようにJSONで指定して付与します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "*"
        }
    ]
}

上記のように書くとs3のデータを更新したり確認したりする権限が付与できます。
さらに、IAMロールを使用できるリソースやユーザーを指定することができます。

どこで？

AWS管理画面のIAMロールのページにアクセスすると以下画像のようなタブが確認できると思います。

「信頼関係」をクリックしてください。
信頼関係も以下のようにJSONで指定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

こうするとEC2にこのIAMロールを使う権限を与えたことになります。

2つのJSONがでてきましたが簡単にまとめると
1つ目のJSONは何をしても良いかを定義し、
2つ目のJSONは誰（awsリソース含む）が使っても良いかを定義しています。

職能機能の管理ポリシー

全然知らなかったのですが、以下のような役割の人に割り当てるのに最適なポリシーがawsで初めから用意されているようです。

  • 管理者
  • Billing (料金)
  • データベース管理者
  • データサイエンティスト
  • 開発者パワーユーザー
  • ネットワーク管理者
  • セキュリティ監査人
  • サポートユーザー
  • システム管理者
  • 閲覧専用ユーザー

実際にaws管理画面で見てみると、

ありますね！
職能機能とは書かずにジョブ機能と書いてありますね。
役割が明確な人のポリシー設計をする場合、職能機能の管理ポリシーが利用できるかを検討すると良いそうです。

パーミッションバウンダリー(Permissions Boundary)

続きましてパーミッションバウンダリーを紹介していきたいと思います。

パーミッションバウンダリー ???
バウンダリーってなに ???

これが最初にパーミッションバウンダリーをきいた時の僕の感想です。全くきいたことなかったです。
まずバウンダリー（Boundary）ですが 境界 という意味みたいです。
読み進めていくと、

パーミッションバウンダリーは、IAMユーザーとIAMロールに対するアクセス制限として動作します。

と、書いてあります。

よく分からん。。IAMポリシーでアクセス制限してなかったっけ？

と、思ったので実際にパーミッションバウンダリーを使用してみました。

awsマネジメントコンソール画面にログイン後、IAMユーザーを作成します。

作成したIAMユーザーでawsマネジメントコンソール画面にアクセスしたいので「アクセスの種類」は「awsマネジメントコンソールへのアクセス」の方にチェックを入れます。それから「次のステップ　アクセス権限」をクリックし、以下画像のように設定します。

職能機能の管理ポリシーの1つである Support User を使ってみました。上記画像の下の方に「アクセス権限の境界の設定」とあるのがわかるでしょうか？それをクリックすると下記画像のようになります。

さらに「アクセス権限の境界を使用してuserの最大アクセス制限を制御する」にチェックを入れるとポリシーを選択できるようになります。ここでも同じく Support User を選択しました。

次に進むと「ユーザーの作成」ボタンが現れるのでそれをクリック

そして

作成されましたね！
permissions-boundary という名前のIAMユーザーを作成しました

このIAMユーザー（permissions-boundary）は現在以下のような状況です

ポリシー
アクセス権限 Support User
パーミッションバウンダリー Support User

アクセス権限、パーミッションバウンダリーともに Support User が付与されている状態ですね
アクセス権限にAmazonS3FullAccessを追加して以下のような状態にします

ポリシー
アクセス権限 Support User
AmazonS3FullAccess
パーミッションバウンダリー Support User

画像

Support User に元から付与されているS3に関する権限も確認しておきましょう。

S3に関しては読み込みだけできるようですね。
AmazonS3FullAccess にはS3のバケットを見るだけではなく、作成したり削除したりできる権限があります。IAMユーザー permissions-boundary には AmazonS3FullAccess の権限も付与したのでアクセス権限だけを見るとS3バケットの作成や削除ができるはずです。

それではawsコンソール画面から一度ログアウトして、先ほど作成したIAMユーザー permissions-boundary としてもう一度ログインしましょう。

ログイン後、S3の画面にアクセスし新しいS3バケットを作成しようとすると

作成できませんでした。「Access Denied」と書いてありますね。

なぜ作成できないのか？

もう一度さきほどの表を見てみましょう

ポリシー
アクセス権限 Support User
AmazonS3FullAccess
パーミッションバウンダリー Support User

このIAMユーザー（permissions-boundary）のアクセス権限には AmazonS3FullAccess がありますが、パーミッションバウンダリーの方にはありません。この制限によってこのIAMユーザーは AmazonS3FullAccess の権限があるにも関わらずS3バケットの作成ができなかったようです。

なるほど、パーミッションバウンダリーの使い方はわかりました。
でも

どういう時に使うの？

と、思ったので調べてみました。
IAMの編集権限は渡したいけどそのユーザー自身に付与できる権限は制限したいといった状況の時に使えそうです。他社の人にIAMユーザーを貸し出す時など上記のように考えることは十分あり得ますね。

というわけでまた実際にやってみました。

さきほどIAMユーザー（permissions-boundary）を作成したと思いますが、このIAMユーザーを作成した時に使っていたIAMユーザーでログインします。

そしてIAMにアクセスしIAMユーザー（permissions-boundary）の権限を編集します。
まずアクセス権限、パーミッションバウンダリー両方の Support User の権限をなくします。次に IAMFullAccess というアクセス権限を付与します。そして AmazonS3FullAccess と IAMFullAccess の両方の権限を持つポリシー（IAM-S3）を作成しパーミッションバウンダリーに指定しました。

表にするとこうです

ポリシー
アクセス権限 IAMFullAccess
AmazonS3FullAccess
パーミッションバウンダリー IAMFullAccess
AmazonS3FullAccess

画像

現状、IAMユーザー（permissions-boundary）にはIAMとS3を自由に編集する権限があります。
それでは一度ログアウトしてIAMユーザー（permissions-boundary）としてログインしましょう。

IAMユーザー（permissions-boundary）はIAMを編集する権限があるので、自身に権限を付与することができます。しかしパーミッションバウンダリーでIAMとS3以外の操作はできないように制限をかけているのでパーミッションバウンダリーで許可した権限以外のことはできないはずです。

試しにEC2を自由に編集できる AmazonEC2FullAccess という権限を自身に与えてみましょう

いや、付与できるんかいっ！！

って思いました。付与することはできるみたいですね笑

現状こんな感じです

ポリシー
アクセス権限 IAMFullAccess
AmazonS3FullAccess
AmazonEC2FullAccess
パーミッションバウンダリー IAMFullAccess
AmazonS3FullAccess

ということは、権限付与はできるけどEC2サーバーを新しく起動したりすることはできないのかなっっと思いEC2の画面にアクセスすると、、

何にもできない状態になっていました。画面にはアクセスできるけど何もできません。パーミッションバウンダリーでEC2を操作するのを許可してないからですね。

確かにこのパーミッションバウンダリーを使えば、他社の人にIAMの編集権限を渡したいが操作できるリソースには制限をかけたいような場合に便利ですね。

パーミッションバウンダリー完全に理解しました。

IAMアクセスアナライザー

IAMアクセスアナライザーを使うと外部のAWSリソースに対して共有しているものを検出することができます。いまのところS3, IAMロール, KMSキー, Lambda, SQSについて調査できるようです。

IAMアクセスアナライザーは設定状況をしらべるものなので、アクセスがあったかどうかはCloudTrailを利用する。

Directory Service

こちら全くきいたことがありませんでした。調べてみるとこう書いてありました。

AWS内でマネージメント型のMicrosoft Active Directory(AD)を利用するためのサービス。

で、でたぁぁ。知らない単語を知らない単語で説明するパターン
そもそもActive Directoryが何なのかを知らなかったので調べてみました。

Active Directoryとは複数のWindowsパソコンを一元的に管理することができる仕組みのこと。

のようです。
参考記事

awsでは以下の3種類のAD関連サービスが使えます。

  • AWS Managed Microsoft AD
  • simple AD
  • AD connector

それぞれどのような場合に使用するかまとめました。

サービス名 どのような場合に使用するか
AWS Managed Microsoft AD フルスペックのMicrosoft ADを構築する場合
simple AD ユーザーID, パスワード管理のみで利用する場合
AD connector オンプレ上の既存ADと繋ぐ場合

オンプレミスとの接続パターンは、AD connectorを使う以外にManaged Microsoft ADを使用するパターンもある。

AD connectorを使う場合は都度オンプレミスのADに認証要求が必要なので遅延等を考慮する必要がある
Managed Microsoft ADを使う場合は、同じリージョンなのでレイテンシーに関して考慮不要

思ったこと・疑問(いつか分かったら追記します。詳しい方教えてください)

  • AWS上にオンプレミスの既存ADのコピーみたいなのを作る感じかな？

Cognito

アプリユーザーの認証認可を行うサービスです。なかでも重要な機能は以下の2つ。

  • ID・パスワードを管理するCognitoユーザープール
  • 認証済ユーザーに一時キーを渡しAWSリソースの操作権限を与えるフェデレーション

フェデレーション ??

調べてみると、

一度認証を通れば、その認証情報を使って、許可されているすべてのサービスを使えるようにする仕組み

と、書いてありました。
参考記事

先に紹介したIAMはAWSを利用するユーザーに対しての認証認可であるのに対して、CognitoはAWS上のシステムに対しての認証認可です。

Cognitoの処理フローを見てみましょう。以下のようになっています。

  1. ユーザーからCognitoユーザープールに認証要求
  2. ユーザープールがtoken返却
  3. 取得したトークンでCognito IDプールに権限要求(認可)
  4. STSに権限要求
  5. STSがIAMロールに紐づく一時キーを発行
  6. ユーザーがIAMロールに紐づく一時キーを取得

シーケンス図を書いてみました

要点整理から攻略する『AWS認定 セキュリティ-専門知識』という本にはもっとわかりやすい図が書かれているのでわかりやすい図を見たい方はご購入ください（アフィリエイトではございません）

Cognitoユーザープールは認証機能を提供し、
Cognito IDプールは認可の機能を提供しています。

Organizations

複数のAWSアカウントをまとめて管理できるサービスです。

まずは以下2つの用語が何を指しているか理解しましょう。
OU: Organizational Unit(組織単位)
SCP: service controll policy

これらが何なのかということですが、OUとSCPはIAMグループとIAMポリシーの関係に近いです。IAMグループはIAMユーザーのグループであるのに対して、OUはAWSアカウントのグループです。そしてSCPでそのアカウントがどういうことができるのかを定義します。

さらにOUはIAMグループとは違い、階層構造を取ることができます。つまり上の階層のルールが下にも引き継がれることになります。

Rootアカウントに対してSCPを適用することもできるが、あまり良くないです。なぜかというと全てのアカウントにそのルールが適用されることになるので例外的なアカウントを作れなくなるからです。

SCPの制約はIAMのみではなくルートユーザーも含みます。非常に強力ですね。

終わりに

最後まで読んでくださった方、ありがとうございます。予想以上に長くなってしまいました。パーミッションバウンダリーの部分に時間と文字数を使い過ぎてしまい、他の部分が少なめになってしまったことをここにお詫び申し上げます。

AWS認定セキュリティの勉強をしたおかげで、パーミッションバウンダリーをはじめ新たな知識を得ることができ大変嬉しく思います。また使えそうな状況があれば積極的に今回学んだサービスを使っていきたいと思います。

最後に今回の勉強で非常に役に立った本を紹介して終わりにしたいと思います。
要点整理から攻略する『AWS認定 セキュリティ-専門知識』

Discussion