Veltioblog

Table of contents

基本的に、IAM とは - AWS Identity and Access Management を読み進めていく感じになる。

IAM とは

AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスを安全に管理するためのウェブサービスです。IAM を使用すると、ユーザーがアクセスできる AWS のリソースを制御するアクセス許可を集中管理できます。IAM により、誰を認証 (サインイン) し、誰にリソースの使用を承認する (アクセス許可を持たせる) かを制御します。

引用: IAM とは - AWS Identity and Access Management

要は AWS サービスの認証認可の役割を担ってくれるサービス

IAM の機能

• AWS アカウント への共有アクセス
• 詳細なアクセス権限
• Amazon EC2 で動作するアプリケーションから AWS リソースへの安全なアクセス
  • これ一番使ってるかも 🤔
• 多要素認証 (MFA)
• ID フェデレーション

  • 他の場所 (社内ネットワーク、インターネット ID プロバイダーなど) でパスワードを既に持つユーザーに、お客様の AWS アカウント への一時的なアクセスを許可できます。

  • こんなことできるのか、今のところ使いたい場面に出会ってないのでちょっとイメージつかない
• 保証のための ID 情報
• PCI DSS コンプライアンス
• 多くの AWS サービスとの統合
• 結果整合性
• 使用料無料
  • 使用量無料だったのを今知った。ありがたい。

IAM へのアクセス

以下のいずれかの方法で IAM を使用できる。

• AWS マネジメントコンソール
• AWS コマンドラインツール (AWS CLI)
• AWS SDK
• IAM Query API
  • 上 3 つは知ってたけどこれは知らなかった。。。
  • HTTP リクエストを直接送信することで IAM を使用できるらしい。
  • SDK はこれのラッパーなのかな？
    • 気が向いたら SDK のコードとか読んでみるか

IAM をいつ使用するか

IAM をいつ使用しますか？ - AWS Identity and Access Management

このページはユースケースが書いてるので、ざっと読んでとりあえず知っておく。

IAM ロールを引き受けるとき

• リリース時コンソール上でロールの切り替えをして、強い権限に昇格してからリリースするっていうことをやってるけど、まさにこれか。
  • ロールの切り替え (コンソール) - AWS Identity and Access Management

IAM の仕組み

IAM の仕組み - AWS Identity and Access Management

IAM のインフラストラクチャーは以下のようになっている。

IAM の仕組み - AWS Identity and Access Managementより引用

基本概念

• 規約
• Principal
• リクエスト
• 認証(Authentication)
• 認可(Authorization)
  • ドキュメントの自動翻訳では認証と記載されているが英語版を見ると Authorization だったので本ブログでは認可と記載する
• アクションまたはオペレーション
• リソース

規約

IAM 用語集

• IAM リソース

  • IAM に保存されているユーザー、グループ、ロール、ポリシー、および IDEA プロバイダー。AWS サービスと同様に、IAM のリソースを追加、編集、削除することができます。

    • 自分の IAM グループが権限なさすぎて、業務中に問題が発生する度に管理者の人に権限付与してもらったの思い出した。
      • 自分はそれを「IAM を育てる」って言ってて、面倒だけどゲーム感覚で楽しんでる。
• IAM アイデンティティ

  • 識別し、グループ化するために使用される IAM リソースオブジェクト。IAM ユーザーにポリシーをアタッチすることができます。ユーザー、グループ、及びロールなどがあります。

• IAM エンティティ

  • AWS によって認証に使用される IAM リソースオブジェクト。これらには、IAM ユーザーおよびロールが含まれます。

• プリンシパル

  • AWS アカウントのルートユーザー、IAM ユーザー、または IAM ロールを使用してサインインし、AWS へのリクエストを行う人またはアプリケーション。プリンシパルには、フェデレーションユーザーと引き受けたロールが含まれます。

  • IAM の引受についてはこちら: IAM ロールを引き受けるとき
• 人間のユーザー

  • Also known as human identities; the people, administrators, developers, operators, and consumers of your applications.

  • 人間 ID とも呼ばれ、人、管理者、デベロッパー、オペレーター、およびアプリケーションのコンシューマーを指します。

  • AWS 語かな？と思って原文読んだけど、割とちゃんと人間 ID だった
• ワークロード

  • アプリケーションやバックエンドプロセスなど、ビジネス価値を提供するリソースやコードの集合体のことです。アプリケーション、運用ツール、およびコンポーネントが含まれることがあります。

Principal

プリンシパルとは、AWS リソースに対するアクションまたはオペレーションをリクエストできる人間の ID またはワークロードです。認証後、プリンシパルには、プリンシパルのタイプに応じて、AWS にリクエストを行うための永続的または一時的な認証情報を付与できます。IAM ユーザーとルートユーザーには永続的な認証情報が付与され、ロールには一時的な認証情報が付与されます。ベストプラクティスとして、人間のユーザーとワークロードに一時的な認証情報を使用して AWS のリソースにアクセスさせることをお勧めします。

あとで読む: IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management

リクエスト

プリンシパルがマネジメントコンソールや、API、CLI を使用するときに AWS に送信されるリクエスト情報について。

• アクション or オペレーション
  • マネジメントコンソールではアクション
  • AWS CLI や API ではオペレーション
• リソース
  • アクションまたはオペレーションを実行する対象の AWS オブジェクト
• プリンシパル
  • エンティティを使用してリクエストを送信するユーザーまたはアプリケーション
  • サインインに使用したエンティティに関連つけられたポリシーも含む
• 環境データ
  • IP アドレス、ユーザーエージェント、SSL 有効化ステータス、または時刻に関する情報
• リソースデータ
  • リクエストされているリソースに関連するデータ
  • これには、DynamoDB テーブル名、EC2 インスタンスのタグ情報などが含まれる場合がある

認可について

リクエストの評価ロジック

• デフォルトでは、すべてのリクエストが拒否されます。(通常、AWS アカウントのルートユーザー 認証情報を使用したアカウントのリソースに対するリクエストは常に許可されます)。

• アクセス許可ポリシー (アイデンティティベースまたはリソースベース) に明示的な許可が含まれている場合、このデフォルト設定は上書きされます。

• Organizations SCP、IAM アクセス許可の境界、またはセッションポリシーがある場合、その許可は上書きされます。上記のポリシータイプが 1 つ以上存在する場合は、そのすべてにおいてリクエストが許可されている必要があります。それ以外の場合、リクエストは暗黙的に拒否されます。

• ポリシー内の明示的な拒否は、すべての許可に優先します。

もっと知りたい場合はこちら: ポリシーの評価論理 - AWS Identity and Access Management

IAM のアクセス許可とポリシー

ポリシーとグループ

ユーザーを IAM グループにまとめ、そのグループにポリシーもアタッチできる。 アクセス管理の概要: アクセス許可とポリシー - AWS Identity and Access Managementより引用

使用目的

• アクセス許可をシンプルにするため
• IAM でのセキュリティのベストプラクティスに従うため

ポリシーアタッチするときだいたいこれ使う気がする。ユーザー個人への権限をつけるより、組織（チーム）に対する権限の付与と考えるほうがシンプルだし、所属が変わったときのポリシーの変更も容易。

🐠 ABAC とは

AWS の ABAC とは - AWS Identity and Access Management

属性ベースのアクセス制御 (ABAC) は、属性に基づいて許可を定義する認可戦略です。これらの属性は、AWS でタグと呼ばれています。タグは、IAM エンティティ (ユーザーまたはロール) を含めた IAM リソース、および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または少数のポリシーのセットを作成できます。これらの ABAC ポリシーは、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。ATBAC は、急成長する環境や、ポリシー管理が煩雑になる状況で役に立ちます。

要はタグベースのポリシー設計ってことかな 🤔

より具体的に理解したい場合は、チュートリアル: IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する - AWS Identity and Access Managementを読むと良さそう。

まとめ

まだドキュメント読んで学習中だが、ABAC なんかは特に実際に試してみないと理解が進まないなと感じたので、今度実際に試しみて、学びがあれば追加でブログを書く予定だ。

IAM のドキュメントを最初から真面目に読んだのは初めてで、意外と知らなかったことが多かったり、知っていた知識についてもより説得力のある情報を得られたりしたので良かったです。😄