認証（Authentication）と認可（Authorization）の違いとは？AWSとAzureの実装で理解するクラウドセキュリティ基礎

クラウドのアクセス管理を設計していると、必ず「認証」と「認可」という言葉が出てくる。ところがこの2つ、正確に区別できているエンジニアが意外と少ない。「ログインできたのにリソースにアクセスできない」「IAMポリシーを設定したのに403エラーが消えない」——そんなトラブルの多くは、認証と認可を混同したまま設計を進めたことが原因だ。

オンプレの時代は、Active DirectoryのKerberos認証とグループポリシーが一体で動いていたため、「ログインできる＝使えるはず」という感覚が染みついている。クラウドでは、AWS IAMやMicrosoft Entra IDによって認証と認可が明確に分離されており、この構造を正しく理解しないとセキュリティホールを抱えたまま本番稼働させてしまいかねない。

この記事では、認証と認可の違いを基礎から整理し、AWSとAzureの実装でそれぞれどう表れるかを現場目線で解説する。

認証と認可はなぜ混同される？オンプレとクラウドの根本的な違い

オンプレ環境では、「ADに登録されているアカウントでログインできる＝そのリソースを操作できる」という暗黙の前提があった。Windowsドメインに参加したサーバーへのRDPアクセスも、ファイルサーバーのSMBアクセスも、ADが認証してグループポリシーが制御するという一体構造だ。

クラウドではこれが完全に分離される。AWS IAMを例に取ると、「AWSのAPIを呼ぶのが誰か（認証）」と「そのAPIで何を操作できるか（認可）」は別々のレイヤーで評価される。どちらかが欠けると、目的の操作はできない。

英語の頭文字で表すと、認証はAuthN（Authentication）、認可はAuthZ（Authorization）と区別される。AWSのドキュメントやAzureのガイドでもこの略語が頻繁に登場するので、覚えておくと読み解きやすい。

認証（Authentication）とは何か

認証とは、「あなたは本当に名乗っている本人ですか？」を確認するプロセスだ。システムへのエントリーポイントで行われ、認証が成功して初めて次のステップ（認可判定）に進める。

認証に使われる要素は大きく3種類に分類される。

・知識情報（Something you know）: パスワード、PINコード、秘密の質問
・所持情報（Something you have）: スマートフォンのOTPアプリ、ハードウェアトークン、SMS認証コード
・生体情報（Something you are）: 指紋、顔認証、虹彩

多要素認証（MFA）はこれら複数の要素を組み合わせることで、パスワード単体の漏洩リスクを大幅に下げる。AWSではIAMユーザーへのMFA設定、Azureでは条件付きアクセスポリシーによるMFA強制が代表的な実装だ。

1. クラウドにおける主な認証手段

クラウドで使われる認証手段は、オンプレとは形が異なる。以下がAWSとAzureの典型的なパターンだ。

・アクセスキー（AWS）/ クライアントシークレット（Azure）: CLIや外部システムがAPIを呼ぶ際に使うクレデンシャル。長期的なシークレットのため、漏洩リスクが高い
・IAMロール / マネージドID: EC2インスタンスやAzure VMなどのクラウドリソース自体にIDを付与し、一時的なトークンで認証する。ベストプラクティスはこちら
・フェデレーション認証（SAML / OIDC）: 企業のIdP（Azure ADや Okta等）を信頼し、社内アカウントでAWSコンソールにSSOする仕組み

2. 一時的な認証トークン（AWS STS）

AWSでIAMロールを使う場合、AWS STS（Security Token Service）が一時的なアクセストークンを発行する。トークンには有効期限（デフォルト1時間、最大12時間）が設定されており、期限切れで自動的に無効になるため、長期シークレットより安全だ。

# AWS CLIでIAMロールを一時引き受けしてトークンを取得（認証の例）
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyRole \
  --role-session-name my-session

# 返ってくるのは一時的なAccessKeyId / SecretAccessKey / SessionToken
# これが「認証成功」の証明トークンになる

認可（Authorization）とは何か

認可とは、「認証済みのあなたは何を操作できますか？」を評価するプロセスだ。認証の後に実行されるため、認証が通っていても認可が拒否すれば操作はできない。

オンプレのグループポリシーと似ているが、クラウドではより細粒度の制御が可能だ。「特定のS3バケットのみ読み取り可、書き込み不可」「特定タグが付いたEC2のみ起動操作を許可」といった条件付きの許可が設定できる。

1. RBAC（ロールベースアクセス制御）とABAC（属性ベースアクセス制御）

認可の設計方針には大きく2つのアプローチがある。

AWSはPBACとABACを組み合わせた柔軟な設計、AzureはRBACをベースにしてロール割り当て＋スコープ（管理グループ～リソース個別）で制御するのが基本だ。

2. AWS IAMポリシーのJSON構造（認可の実体）

# IAMポリシーの例（認可の設定）
# 「特定S3バケットのオブジェクト取得のみ許可、削除は拒否」
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}
# Effect（Allow/Deny） + Action（操作） + Resource（対象） の3要素が基本

認証と認可の処理フロー

2つの概念の関係を処理の流れで整理する。クラウドAPIの呼び出しは、必ずこの順序で評価される。

# クラウドAPI呼び出し時の評価フロー

[1] 認証（Authentication）
    ↓ アクセスキー / ロールトークン / フェデレーション証明書
    ↓ 「このリクエストは誰からのものか？」を検証
    ↓ 失敗 → 401 Unauthorized（認証失敗）

[2] 認可（Authorization）
    ↓ IAMポリシー / Azure RBAC を評価
    ↓ 「認証されたこのIDはこの操作を許可されているか？」
    ↓ 失敗 → 403 Forbidden（認可失敗）

[3] アクセス成功
    ↓ リソース操作が実行される

「401」と「403」はHTTPステータスコードだが、クラウドのエラーレスポンスでも同様の意味を持つ。本番で403が出たとき、「認証は通っているが認可が通っていない」と読み解けると、トラブルシューティングの精度が上がる。

AWSにおける認証と認可の実装

1. IAMユーザー・ロールによる認証

AWSへのアクセスを「誰として」行うかを決めるのがIAMエンティティだ。大きく3種類に分かれる。

・IAMユーザー: 人間が使うアカウント。アクセスキーIDとシークレットアクセスキーが認証手段。長期利用のため、可能な限りロールに移行するべきだ
・IAMロール: EC2インスタンス、Lambda関数、ECSタスクなどのAWSリソースに付与するID。AWS STSが一時トークンを発行する。ベストプラクティスとして推奨される
・フェデレーションユーザー: SAMLやOIDCで外部IdPと連携し、一時的な権限を取得する。AWS IAM Identity Centerを使えば、組織全体のSSOが実現できる

EC2インスタンスからS3にアクセスする場合、アクセスキーをコードにベタ書きするのは厳禁だ。インスタンスにIAMロールをアタッチし、EC2メタデータサービス（IMDS）から一時トークンを取得する方式が正しい。

# EC2インスタンスにアタッチされたIAMロールのトークン確認
# （EC2メタデータサービスから一時認証情報を確認する例）
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
# → ロール名が返る

curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole
# → AccessKeyId, SecretAccessKey, Token（一時認証情報）が返る
# AWS SDKはこれを自動取得するため、コードへのキー埋め込みは不要

2. IAMポリシーによる認可

「誰として」の認証が確定したら、「何ができるか」をIAMポリシーで評価する。AWSの認可はデフォルト拒否（Implicit Deny）が基本だ。明示的なAllow設定がなければ、すべての操作が拒否される。

ポリシーには2種類ある。

・管理ポリシー（Managed Policy）: AWSが管理するポリシー（ReadOnlyAccess等）と、ユーザーが作成するカスタム管理ポリシー。複数のIAMエンティティにアタッチ可能
・インラインポリシー（Inline Policy）: 特定のIAMエンティティに直接埋め込む。1対1の対応なので、再利用はできない

最小権限の原則（Least Privilege）を守ることがセキュリティの基本だ。まず全操作を拒否し、必要な操作だけを明示的にAllowするアプローチが推奨される。IAMの詳細な設計と運用については、AWS IAM入門の記事も参照してほしい。

3. Amazon Cognitoの役割

アプリケーションのエンドユーザー向け認証・認可には、Amazon Cognitoを使う。

・User Pool（ユーザープール）: ユーザー認証を担当。メール+パスワード、ソーシャルログイン（Google/Facebook）、SAMLフェデレーションに対応
・Identity Pool（IDプール）: 認証済みユーザーにAWSリソースへの一時的なIAM認証情報を付与する。S3バケットへのアクセス権をエンドユーザー単位で制御できる

Azureにおける認証と認可の実装

1. Microsoft Entra IDによる認証

AzureのIDプラットフォームはMicrosoft Entra ID（旧称: Azure Active Directory）だ。OAuth2.0とOpenID Connect（OIDC）をベースにしており、組織アカウントのログインからAPIアクセストークンの発行まで一元管理する。

Azureで使われるIDの種類は以下の3つだ。

・ユーザー（User）: 組織のEntra IDに登録された人間のアカウント。メール+パスワード+MFAで認証
・サービスプリンシパル（Service Principal）: アプリケーションやCIパイプラインが使うアプリID。クライアントIDとクライアントシークレット（または証明書）で認証
・マネージドID（Managed Identity）: Azure VMやApp ServiceなどのAzureリソースに付与するID。秘密情報の管理が不要で、AWSのIAMロールに相当するベストプラクティス

条件付きアクセス（Conditional Access）を使うと、「特定の場所からのみログインを許可」「MFAが完了していないとアクセス拒否」「管理されていないデバイスからは制限」といった動的なポリシーを認証フローに組み込める。

2. Azure RBACによる認可

Azureの認可はAzure RBAC（Role-Based Access Control）で管理する。IAMポリシーのようなJSONを個別に書くのではなく、ロールをスコープに割り当てるシンプルな設計だ。

スコープは管理グループ → サブスクリプション → リソースグループ → 個別リソースの4階層があり、上位スコープに割り当てたロールは下位に継承される。「プロジェクトAのリソースグループだけContributorを付与する」といった細粒度の制御も可能だ。

# Azure CLIでロールを割り当てる（認可の設定）
# サービスプリンシパルに特定リソースグループのContributorを付与
az role assignment create \
  --assignee <サービスプリンシパルのオブジェクトID> \
  --role "Contributor" \
  --scope /subscriptions/<サブスクリプションID>/resourceGroups/<リソースグループ名>

# 現在のロール割り当て確認
az role assignment list \
  --assignee <サービスプリンシパルのオブジェクトID> \
  --output table

よくあるトラブルと対処法

1. 403エラーが消えない

認証は通っているが認可が不足しているケース。確認すべき点は以下だ。

・AWSの場合: IAMポリシーに必要なActionとResourceが明示的にAllowされているか確認する。SCPやリソースベースポリシー、アクセスコントロールリスト（ACL）が上書きしていないかも確認する
・Azureの場合: ロール割り当てのスコープが正しいか、カスタムロールの`actions`に必要な操作が含まれているか確認する

AWS IAM Access Analyzerを使うと、意図しない公開設定や過剰な権限を自動検出できる。権限設計のレビューに活用したい。

2. IAMロールのAssumeRoleが失敗する

IAMロールを引き受けようとしたときに「not authorized to assume role」エラーが出るケース。ロールの信頼ポリシー（Trust Policy）が設定されていないか、信頼元のプリンシパルが誤っていることが原因だ。

# IAMロールの信頼ポリシーの例
# EC2インスタンスがこのロールを引き受けられるように設定
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
# 「誰がこのロールを使えるか（認証元の信頼関係）」と
# 「このロールで何ができるか（認可ポリシー）」は別ファイルで管理する

3. マネージドIDでAzureリソースにアクセスできない

Azure VMにシステム割り当てマネージドIDを有効化した後も403エラーが出る場合、マネージドIDへのRBAC割り当てが漏れているケースが多い。マネージドIDのオブジェクトIDを確認し、対象リソースへのロールを明示的に割り当てること。

4. 本番とステージングで権限の動作が違う

環境をまたいで同じポリシーをコピーしても、Azureのサブスクリプションが異なれば権限が引き継がれない。RBACはサブスクリプション単位でスコープを持つため、環境ごとに割り当てを確認する必要がある。TerraformやAWS CloudFormationでIaCとしてポリシーを管理すると、環境差分の見落としが減る。

本記事のまとめ

認証と認可は「どちらが欠けても成立しない」セキュリティの両輪だ。オンプレのAD一体型から、クラウドの明示的な2層構造へ——この切り替えを意識して設計するだけで、アクセス制御まわりのトラブル対応がかなり楽になる。クラウドセキュリティのさらなる設計原則については、責任共有モデルやゼロトラストセキュリティの記事もあわせて参考にしてほしい。