アイデンティティとアクセス管理

概要

IAMは、誰が何にアクセスできるか、どのような条件でどのように制御されるかを提供するプロセス、ポリシー、およびツールのコレクションです。目的：冗長な権利の最小化、攻撃面の削減、オンボーディングと監査の加速、コンプライアンス（PCI DSS、 GDPRなど）、および測定可能なアクセス信頼性。

基本的なコンセプト

身元：人（従業員、請負業者）、サービス/アプリケーション、デバイス。
認証（AuthN）：誰がチェックするか（パスワード→MFA→パスワードフリーのFIDO2/passkeysスキーム）。
認可（AuthZ）：「許可されているもの」（RBAC/ABAC/ReBAC、ポリシー）の決定。
資格情報：パスワード、キー、トークン、証明書（mTLS）。
秘密管理：KMS/HSM/Vault、回転、短いTTL、動的秘密。
ライフサイクル：Joiner-Mover-Leaver （JML）-役割の作成、変更、リコール。

ターゲットIAMアーキテクチャ

飛行機と役割：

IdP （IDプロバイダ）：SSO、 MFA、ディレクトリ、フェデレーション（OIDC/SAML）、リスクポリシー。
PDP/PEP：意思決定/執行-ポリシーエンジン（OPA/Cedar）+アプリケーションポイント（APIゲートウェイ、プロキシ、サービスメッシュ）。
カタログ/人事制度：従業員と役割による真実の源
プロビジョニング：SCIM/Automationによるアクセスの作成/変更/取り消し。
監査：集中ログ、UEBA、ロールおよびアクセスレポート。

アクセスフロー（ユーザー→アプリ）：

SSO（+MFA）→トークン発行（OIDC/JWT/SAML）→PEPがトークン/コンテキストをチェック→PDPがポリシー（role/attributes/risk）→アプリケーションのissue/deniesアクセスを決定します。

認証： パスワードからパスキーへ

パスワード：パスワードマネージャでのみ、少なくとも12-14文字、回転なし「カレンダーに従って」、しかし、インシデントの場合には必須と。
デフォルトMFA： TOTP/WebAuthn/Push；主要な要因としてSMSを避けて下さい。
パスワードなしログイン：重要なドメインのFIDO2/passkeys。
Adaptive AuthN：リスクシグナル（地理、ASN、デバイス、異常）→追加のファクター/ブロックが必要です。

承認： RBAC、 ABAC、 ReBAC

RBAC：関数（サポート、ファイナンス、DevOps）に対応する役割。シンプルでわかりやすいですが、「成長」しています。
ABAC：属性のルール（部門、リスクレベル、時間、ゾーン、リソースラベル）。スケーラブル。
ReBAC：「誰が何に属するか」の関係（プロジェクトオーナー、チームメンバー）。マルチテナントのシナリオに便利です。

ベストプラクティス：

RBAC（ベースグリッド）+ABAC/ReBAC（コンテキスト/バウンド）を組み合わせます。
JIT （Just-In-Time）：リクエスト/アプリによる一時特権の発行、自動失効。
JEA （Just-Enough Access）：運用に必要な最低限の権利。
PAM：セッションブローカー、スクリーン/コマンドの記録、短期間のクレジットの発行で、孤立した「強力な」アクセス（DB/クラウド管理者）。

フェデレーションとSSO

プロトコル：OIDC （JWTトークン）、SAML 2。0 （XMLアサーション）-外部プロバイダ/パートナー向け。
SSO： MFA、フィッシング削減、集中リコールを備えた単一のエントリポイント。
B2B/B2C：パートナーとのフェデレーション、ドメイン制限、ドメインベースのポリシー。
mTLS/m2m：サービスでは、短命のx。509 （SPIFFE/SVID）またはOAuth2クライアント資格情報を使用します。

ライフサイクル（JML）とプロビジョニング

Joiner：アカウントの自動SCIMプロビジョニングとHR/ディレクトリからの基本的な役割。
Mover：役割は属性（部門、プロジェクト、場所）によって自動的に変更されます。
Leaver： SSO、キー、トークン、リポジトリ/クラウド/CI/CDアクセスの即時リコール。
プロセス：アクセスリクエスト（ITSM）、 SoDマトリックス（職務分担）、定期的なアクセスレビュー。

秘密、鍵、回転

KMS/HSM：ルート/クリティカルキーを保存し、操作監査を有効にします。
Vault/Secretsマネージャ：Dynamic credits （DB、 cloud）、 auto-revok at TTL complete。
ローテーション：OAuthトークン、JWT署名キー、サービスパスワード-予定通り、インシデントが発生した場合。
mTLS：短命の証明書（時間/日）、自動再発行。

ポリシーとソリューションエンジン

宣言性： Gitにポリシーを保存する。check in CI（ポリシーテスト）

コンテキスト：時間/場所/ASN/リスクレベル/デバイスステータス（MDM/EDR）。

例（Rego、簡略化）：

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

モニタリング、SLO、監査

メトリクス：

AuthN/AuthZ（％）、p95ログイン/意思決定時間、MFA/パスワードなし入力の共有の成功。
JIT/PAMエスカレーション数、平均特権期間。
準拠デバイスのカバレッジ、短命の秘密の共有。

SLO（例）：

SSO/IdP ≥ 99の可用性。1ヶ月あたりの95％。
p95 AuthZの決定≤ 50ミリです。
アカウントの100％シャットダウン≤オフボーディング後15分です。
監査とUEBA：集中型の不変ログ（アクセス、ロール変更、失敗した入力、PDPソリューション）、行動分析、異常アラーム。

IAMにおけるインシデント対応

トークン/キーの妥協：即時失効、強制ログアウト、署名キーの回転、短命の秘密の再発行。
権利の乱用：アカウントを停止し、JIT/JEAをブロックし、近隣の事業体のアクセスレビューを行います。
IdPは利用できません：オフラインモード（短いTTLでトークンの一時的なキャッシュ検証）、優先回復手順。
フィッシング：必須MFA、セッションのリスクチェック、ユーザーへの通知、トレーニング。

雲とKubernetes（パターン）

パブリッククラウドIAM：最低権限でネイティブロールを使用します。「eternal」キーの代わりに、OIDCフェデレーションをクラウド（IRSA/Workload Identity）にワークロードします。
Kubernetes： RBAC by neimspaces/roles、 limit 'cluster-admin'；秘密-外部マネージャーを通じて；L7ポリシーのサービスメッシュ+OPA；入場管理者（サイン入り画像、禁止事項「：latest」）。
APIゲートウェイ：JWT/mTLSのチェック、レート制限、リクエストシグネチャ（HMAC）による機密性の高いエンドポイントの確認。

iGaming/fintechの練習

アクセスドメイン：支払い、不正防止、PII、コンテンツプロバイダ-役割とネットワークセグメントを分離します。
SoD：競合する役割を組み合わせないでください（例：プロモーションを作成する+支払いを承認する）。
PAMとJIT： PSP/banksとprod-DBへのアクセスのために-唯一のセッションブローカーを介して、録音とオートリコールで。
コンプライアンス：PCI DSS-MFA、最小特権、CHDゾーンのセグメンテーション；GDPR-PIIへのアクセスのデータ最小化とポイントログの原則。
パートナーおよびコンテンツプロバイダー：フェデレーションおよびテナントポリシー;短命トークンとIP/ASN allow-list。

よくあるエラー

「永遠の」キーとトークン：ローテーションとTTL→リークのリスクが高い。
手動オフボーディング：権利の取り消し→「ghostly」アクセスの遅延。
モノリスの役割：コンポジションと属性の代わりに1つの「スーパーロール」。
管理パネルでのみMFA： MFAはすべての入力および重要な操作のためにあるべきです。
ログ「どこにもない」：集中化とUEBA→後でインシデントを検出することはありません。

IAM導入ロードマップ

1.ユーザー/サービス/リソースのインベントリ；データと感度マップ。
2.すべてのためのSSO+MFAは、フィッシング抵抗力がある要因を含んでいます。
3.ロールモデル：コンテキストの基本RBAC+属性（ABAC）；SoD行列。
4.SCIMプロビジョニング：人事/カタログからの権利の自動作成/変更/失効；ITSMのアプリケーションと更新。
5.PAMおよびJIT/JEA：特権アクセス用；録音セッション、短いTTL。
6.秘密管理：静的なキーの拒絶；動的秘密、回転、短い証明書を持つmTLS。
7.Git+CIのポリシー：ルールテスト、変更制御、カナリアポリシーの展開。
8.観測可能性とSLO： AuthN/AuthZダッシュボード、アラート、定期的なアクセスレビュー。

アーティファクトの例

AWS IAMポリシー（S3レポートを読むための最小限）

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC（名前空間スコープ付き開発者）

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC： ABACの承認（例）

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

このポリシーは、リソースと一致するように'device_compliant=true'と'tenant'を必要とする場合があります。

チェックリスト

SSOはすべてのアプリケーションで有効です。デフォルトではMFA、優先度のパスキー。
RBAC定義；ABAC/ReBAC add context；JIT/JEAによって実装されました。
PAMは特権アクセスを保護します。セッションが記録されています。
人事からのSCIMプロビジョニング；オフボーディングは完全に自動化されています。
秘密は動的で、短いTTL；回転は自動化されます。
ポリシーはGitでバージョン管理され、CIでテストされます。カナリア計算があります。
AuthN/AuthZによるダッシュボードとSLO；一元管理されたログとUEBA。
定期的なアクセスレビューとSoDチェック。コンプライアンス報告書。

よくあるご質問

ReBACは誰もが必要ですか？
いいえ、そうではありません。RBAC+ABACはシンプルな環境で十分です。ReBACは、リソース所有権とマルチテナンシーの複雑な階層において有用です。

ローカルアカウントを残すことはできますか？
厳格な制限と定期的な検証で、ブレイクガラスとオフラインシナリオのみ。

「役割の爆発」を減らす方法は？
リソースの粒度を高め、ABAC/テンプレートを使用し、レビューを自動化し、未使用のロールを破棄します。

合計

成熟したIAMアーキテクチャは、SSO+MFA、必要最小限の権利、自動化されたJML、集中化されたポリシー、および観測可能性です。RBACと属性とリレーショナルモデルを組み合わせ、JIT/JEAとPAMを適用し、プロビジョニングとシークレットローテーションを自動化することで、セキュリティとビジネス要件を満たす管理、監査、スケーラブルなアクセスを得ることができます。