要点
- 認証は、パスワード、パスキー、多要素認証プロンプトなどを通じて個人の認証情報を識別し、その本人確認を行うことで、「あなたが誰であるか」を確認します。
- 認可は、検証済みの各ユーザー/ワークロードにどのロール/属性/ポリシーが適用されるかを評価することで、「何ができるか」を判断します。認証後に、どのリソース/アクションへのアクセスが許可されるかを決定します。
- OpenID Connect (OIDC) は認証に使用され、OAuth 2.0 は API/サービスの委任ベースの認可に使用されます。
- 認証と認可を混同すると、深刻な設計ミスにつながる可能性があります。たとえば、有効なログインに対して突然あらゆる操作を実行する権限を付与してしまうこと（たとえその権利がなくても）、ユーザーに過剰な権限を持つロールを割り当てること、追跡・管理・監査が困難な権限のハードコードされたチェックに依存することなどです。
はじめに
現在、インターネットはあまり良い状態ではなく、崩れつつあります。cPanel と WHM の認証バイパス CVE-2026-41940 は、いまだに多くのホスティングプロバイダーが古いバージョンにとどまっていること、そしてその潜在的な影響範囲が実際にどのようなものかを示しました。しかも、このエクスプロイトはすべてのバージョンに影響します。
侵害を受けた場合に備えて、強力なネットワークセグメンテーションの背後でインフラを保護することの重要性を改めて思い出させる事例です。
Microsoft も最近、13,000 以上の組織にまたがる 35,000 人超のユーザーを標的とした大規模な多段階フィッシングキャンペーンに直面しました。攻撃者は Adversary-in-the-Middle (AiTM) 技術を使用して MFA を回避し、セッションクッキーを盗みました。
これが分かりにくく、認証攻撃と認可攻撃の違いが分からない場合は、そのまま読み進めてください。以下で説明します。
認証とは何か？
認証は、ユーザーに本人であることを証明させ、機密データを不正アクセスから保護します。不正な侵入を防ぎ、システムにログインするためにユーザー名やパスワードなどの認証情報の提示を求めます。
デジタル以外の用途では、公証された文書の確認が必要になります。予防的セキュリティにおいて、認証は機密データを保護するために使用されます。
一般的な認証方式
認証では、本人確認のために以下の要素の 1 つ以上に依存します。
- パスワード、PIN、本人だけが知っている一般的な秘密の質問への回答
- スマートカード、ハードウェアトークン、OTP
- 指紋スキャン、顔認識、虹彩スキャンなどの生体認証
認証攻撃の種類
認識しておくべき一般的な認証攻撃の種類は次のとおりです。
- クレデンシャルスタッフィングとブルートフォース。 過去の侵害で流出したユーザー名とパスワードの組み合わせを再利用したり、レート制限が不十分な場合に脆弱なログインを集中的に試行したりします。
- フィッシングと MFA 疲労。 多くの場合、信頼できるブランドを装うソーシャルエンジニアリングを通じて、ユーザーをだまして認証情報を明かさせたり、プロンプトを承認させたりします。
- セッションハイジャック。 ブラウザ、デバイス、またはメモリからトークンを盗み、攻撃者がログインフォームを完全に回避できるようにします。
- デバイス侵害。 すでにチェックを通過した信頼済みデバイスを乗っ取り、それに伴うセッションコンテキストを悪用します。
認可とは何か？
認可は、ログイン済みユーザーがネットワークまたはシステム内で何を実行できるかを確認するセキュリティプロセスです。基本的には、「何ができるか」または「何を行うことが許可されているか（許容される権限の範囲内で）」を示します。
認可は、認証が成功した後にのみ行われ、前には行われません。ユーザーのアイデンティティを一連のルールまたはポリシーに照らして評価し、それに応じて特定のリソースへのアクセスを許可または拒否します。
認可モデルとプロトコルの種類
認識しておくべき一般的な認可ロールモデルの種類は次のとおりです。
- ロールベースアクセス制御 (RBAC): 権限は個々のユーザーではなく、管理者、編集者、閲覧者などの特定のロールに付与されます。 企業エコシステムで最も一般的に使用されるモデルの 1 つです。
- 属性ベースアクセス制御 (ABAC): これは、属性を使用して判断を行う非常に柔軟な認可モデルです。ユーザーや部門の詳細、リソースタイプ情報、環境コンテキスト（デバイスセキュリティ、場所、時刻など）を含めることができます。
- 任意アクセス制御: リソース所有者が、誰が何にアクセスできるか、誰がそれにアクセスできるかを完全に制御します。Google drive や Windows フォルダーでのファイル共有のようなものです。
- 強制アクセス制御 (MAC): 厳密に定義されたセキュリティラベルに基づいてアクセスが決定される、最も制限の厳しい認可モデルの 1 つです。機密情報を中央管理し、軍事や高度なセキュリティが求められる政府システムで非常によく使用されます。
- 関係ベースアクセス制御 (ReBAC): アクセスは、ユーザーとリソースの関係に基づいて決定されます。これはややパーソナライズされたもので、リソースの所有者であることや、メンバーが特定のフォルダーの一部であることに近い考え方です。
また、最新の認可タイプとプロトコルについて知っておくべきことは次のとおりです。
- OAuth 2.0: 委任認可の業界標準です。パスワードを見せることなく、サードパーティ製アプリがあなたのデータにアクセスできるようにします。
- JSON Web Tokens (JWT): 2 者間でクレームを表現するためのコンパクトで URL セーフな方法です。サーバーは誰かがログインしたときに JWT を発行し、これは基本的に「ユーザーは X に対して認可されている」と示すもので、後続の他のリクエストを確認するために提示することもできます。
- アクセス制御リスト (ACL): これはリソースに付随するシンプルなリストで、ユーザーとグループの名前が記載されます。また、それらが持つ権限も示されます。唯一の欠点は、企業の成長に伴って大規模になるほど管理がはるかに難しくなることです。
認証と認可の重要な違い
認証と認可の違いは一文で要約されることがよくありますが、設計作業にはより詳細な理解が必要です。ここでは、認証と認可が分岐する領域を示します。
1. アクセスフローにおける順序
認証は認可の前に行われます。認証フェーズでは、Identity Context が作成されます。その後、認可フェーズでは、特定のアクションを許可するかどうかを判断する際に、この Identity Context が考慮されます。
言い換えると、これらのフェーズを単一のプロセスとして扱わず独立して実行できるようにすることで、「ユーザーはすでに認証済み」であっても、その後の各ステップをセキュリティの観点から検証できます。健全なシステムでは、あらゆる機密性の高いアクションが両方のレイヤーを通過します。
2. 使用されるデータ
認証では、パスワード、PIN、秘密の質問への回答、所持要素（メールや SMS による OTP、ハードウェアトークンのシリアル番号、デジタル証明書など）、生体要素（指紋テンプレート、顔の幾何学的スキャン、虹彩パターン）、およびエンティティ ID（メールアドレス、従業員 ID、ユーザー名などの一意識別子）が使用されます。
認可では、権限ルールに関連するデータ、たとえばアイデンティティに割り当てられたラベル（ユーザーロール）、ユーザーおよびリソース属性（アクセス対象の人やオブジェクトに関する特定のメタデータ）、環境コンテキスト（IP アドレス、デバイスの健全性、時間、場所）が使用されます。
3. 失敗モードとエラーハンドリング
認証失敗エラーは通常、無効な認証情報メッセージまたは CAPTCHA/MFA チャレンジにつながり、繰り返し試行すると通常はユーザーアカウントがロックされます。一方で、認可失敗エラーは、禁止メッセージを返したり、リソース情報を隠したり、アクセス制御権限のために追加の認可を求めたりします。
認証/認可失敗エラーを標準エラーやサイレント失敗エラーとして扱うと、インシデント対応が複雑になります。認証エラーと認可エラーを適切にログ記録し区別することで、対応担当者は攻撃者が入口に到達したのか、それとも内部を探索しているのかを判断できます。
4. 所有権と責任
認証の所有権は一般に、アイデンティティチーム、またはシングルサインオン (SSO)、MFA、ID プロバイダーを扱うプラットフォームチームにあります。一方、認可の所有権は、アプリケーションチーム、セキュリティチーム、および各アクションに何が必要かを理解しているデータ所有者の間にまたがります。
1 つのチームが全面的に管理している一方で、ビジネスオーナーに相談していない場合、権限にずれが生じる可能性があります。
認証と認可: 主な違い
認証と認可をひと目で比較または概観したいですか？ 以下はクイックリファレンスです。
| 機能 | 認証 | 認可 | 例 |
| 主要な問い | ユーザーまたはワークロードが誰であるかを検証します。 | そのアイデンティティが何にアクセスできるかを決定します。 | 従業員が MFA でログインし、その後ポリシーによって閲覧可能な HR レコードが決定されます。 |
| 一般的なデータ | 認証情報、生体情報、デバイスまたはワークロードのアイデンティティ。 | ロール、属性、リソースラベル、リスクスコア。 | ある API 呼び出しには、ID トークンに加えてロールクレームとプロジェクトタグが含まれます。 |
| 主な標準 | OIDC、SAML、プラットフォームのサインインプロトコル。 | OAuth 2.0、ポリシーエンジン、ABAC および RBAC ルール。 | OIDC はユーザーをログインさせ、OAuth スコープは呼び出し可能な API を定義します。 |
| 実行されるタイミング | 保護されたリソースにアクセスする前。 | 認証後のすべてのアクセス判断時。 | ユーザーセッションは有効でも、高リスクの送金では追加チェックが引き続きトリガーされます。 |
| 失敗時の挙動 | ログインをブロックするか、追加の証明を求めます。 | 特定のアクションを拒否し、リソースを隠すか、レビューのためにエスカレーションします。 | パスワードリセットの失敗と、「許可されていません」と表示される支払い承認画面の違い。 |
企業が犯しがちな認証と認可の一般的なミス
ここでは、すべての企業が避けるべき一般的な認証と認可のミスを挙げます。
ログインを唯一のゲートとして扱う
他のチームは、ユーザーがすでにログインしていれば、アプリケーション内でその人が行うことは何でも許容されると考えるかもしれません。その結果、すべてのデータを一度にエクスポートする、設定を変更する、トークンを生成するといった高リスクなプロセスが、その 1 回のログインプロセスだけに依存することになります。
重要なアクションは、認可、リスク評価、さらには認証について独自のチェックを実行する独立した制御ゲートとして扱うべきです。たとえば、送金に対して MFA 要件を引き上げることなどが考えられます。
過剰な権限を持つロールと「念のため」の権限
チームメンバーが「素早く動ける」ように広範な権限を与え、問題は後で整理しようとするのは自然な発想です。認可エラーに関する調査では、この「後で」は決して訪れず、時間の経過とともにアカウントに不要な権限が蓄積し、攻撃者に悪用されることが明らかになっています。
最初からスコープの狭いロールを設計し、それらが実際の業務に整合していることを確認する方が、より良い成果につながります。不要な権限を排除することと同様に、レビューのプロセスはアクセス再認証の取り組みに不可欠です。
アプリケーションコード内のハードコードされたチェック
認可ロジックが異なるサービス間に分散している場合、新しい製品のリリースごとに権限アクセスの回帰リスクが生じます。開発者が「if user.is_admin」のようなコピー＆ペーストの手法を使うと、一部のエッジケースを見落とし、監査担当者の作業を難しくする可能性があります。
この問題は、権限ロジックをポリシーまたは専用サービスに集約し、セキュリティチームやコンプライアンスチームがアクセスできるようにすることで軽減できます。製品側はどのポリシーを使用すべきかを決定しつつ、権限自体は中央管理されます。
ゼロトラストと最新アーキテクチャにおける認証と認可
ゼロトラストアーキテクチャでは、アイデンティティが新たなセキュリティ境界になりつつあります。システムはセッション全体を通じて、ユーザーのアイデンティティとデバイスの健全性を継続的に検証しています。権限はもはや静的ではなく、幅広いリアルタイムシグナルに基づいて各リクエストの時点で評価されます。
最新の認可エンジンは、アクセスを許可する前にこれらのシグナルを評価するために Policy Decision Points (PDPs) を使用します。リソースの機密性、デバイスポスチャ、ユーザーアイデンティティ、場所/ネットワークを考慮に入れます。
クラウドネイティブ環境では、認可が人間だけを対象とするものではないため、Machine-to-Machine (M2M) セキュリティも考慮されています。サービスアイデンティティ（人間ではないユーザー）も、SPIFFE や MTLS のような最新プロトコルを使用する前に認証および認可されるようになっており、自動化システムがネットワーク内をラテラルムーブメントすることを防ぎ、結果として後続の侵害を防止します（1 つが侵害された場合でも）。
より安全な認証・認可フローを設計する方法: 認証と認可のベストプラクティス
優れた認証と認可の設計は先を見据えています。レガシーな脅威モデルではなく、2026 年に攻撃者がどのようにアイデンティティを悪用しているかに備えて組織を準備します。以下は、今すぐ採用を始められる認証と認可のベストプラクティスです。
- サインインには OIDC、API アクセスには OAuth を使用する。 アイデンティティの証明と委任アクセスを分離することで、責務を混同することなく、認証には ID トークン、認可にはスコープを検証できます。
- 後片付けの作業としてではなく、設計段階から最小権限を採用する。 実際の職務に対応するロールとポリシーを構築し、強力な権限には正当化を求め、攻撃者に見つかる前に未使用の権限を削除するための定期的なアクセスレビューを予定します。
- 分散したチェックよりもポリシーベースの認可を優先する。 アクセスルールを専用のポリシーエンジンまたはサービスに移し、すべての機密性の高いアクションについてアプリケーションがそれらを呼び出すようにします。これにより、監査、変更、テストを 1 か所に集約できます。
- 継続的かつリスク認識型の認証を有効にする。 認証情報の漏えい、デバイスポスチャ、地理的位置、行動分析などのシグナルを組み合わせ、高リスクなアクションで MFA のステップアップやトークン失効をトリガーするようにし、単一のログインイベントに依存しないようにします。
- トークンの有効期間を短縮し、Just-in-Time 昇格を使用する。 狭いスコープを持つ短命なトークンを発行し、誰かが要求して追加チェックを通過した場合にのみ一時的な管理者アクセスを付与します。そのアクセスはタスク完了後に自動的に失効させます。
- アイデンティティログをエンドポイントおよびワークロードのテレメトリと統合する。 認証および認可イベントを、EDR とクラウドワークロードのシグナルを取り込む同じデータレイクにストリーミングすることで、アイデンティティ、デバイス、ワークロードの境界をまたぐ攻撃を追跡できます。
- 成功パスと同じくらい慎重に失敗パスをテストする。 認証および認可条件を意図的に失敗させる自動テストやカオススタイルの演習を追加し、エラー、アラート、ログ記録が期待どおりに動作することを確認します。
これらのプラクティスを一貫して実践すれば、「謎の管理者」アカウントは減り、インシデント時の帰属はより明確になり、攻撃者が盗んだアイデンティティを制御が反応する前に利用できる時間枠も大幅に小さくなります。
SentinelOne がアイデンティティセキュリティを強化する方法
SentinelOne の Singularity Platform は Autonomous Security Intelligence (ASI) によって支えられています。これは、悪意のある挙動を特定し、重要な作業を自動化し、脅威にマシンスピードで対応する、プラットフォームの基盤に組み込まれたインテリジェンスファブリックです。ID プロバイダーが誰がログインでき、何にアクセスできるかを管理する一方で、Singularity Identity はセキュリティ実施レイヤーを追加します。つまり、認証情報の悪用を検出し、ラテラルムーブメントを阻止し、標準的なアクセス制御を回避する脅威から認証および認可ポリシーを保護します。
Singularity™ Identity を使用してアクセス試行を監視およびブロックし、脅威アクターがエンドポイントからユーザー認証情報を収集するのを防ぐことができます。
Singularity Identity の条件付きアクセスポリシーは、ユーザーまたはデバイスから不審な挙動が検出された場合に、追加の MFA プロンプトなどのステップアップ認証を自律的にトリガーできます。また、ログインイベントをデバイスの健全性や行動シグナルと相関させることで、MFA 疲労を防ぎ、バイパス攻撃を許しません。
Singularity Identity は、公開されたサービスアカウント、脆弱なパスワード設定、Active Directory の設定ミスなど、認証インフラ全体の弱点を攻撃者に悪用される前に継続的に特定します。詳細は Singularity Identity の製品ページをご覧ください。また、SentinelOne を使用して権限昇格を防止し、すでに認証されているものの管理者権限または root 権限を取得しようとしている攻撃者をブロックすることもできます。これにより、ラテラルムーブメント攻撃を防ぎ、その場で阻止できます。
SentinelOne は deception technology とおとりを使用して、本来見るべきではないデータにアクセスしようとする不正ユーザーに自らの存在を明らかにさせます。ゼロトラストアーキテクチャでは、Singularity Identity は意図の継続的な検証を提供し、ユーザーの行動が認可された機能から逸脱した場合にはマシンスピードでアクセスを取り消すことができます。また、アクセス制御リスト (ACL) の設定ミスも特定し、対処できます。
ハイブリッド環境全体でリアルタイムのアイデンティティ保護とエンドツーエンドの可視性を実現し、露出の検出、認証情報の悪用防止、アイデンティティリスクの低減を行います。
結論
認証と認可はどちらもクラウドとサイバーセキュリティの一部です。人間ユーザーと非人間ユーザーの両方を扱う限り、その両方が必要になります。これらは、環境内であらゆるアカウント、サービス、エージェントがどのように振る舞うかを形作る設計上の判断です。これらを別個のレイヤーとして扱い、継続的な検証ワークフローに接続することで、悪用されたアイデンティティをはるかに容易に発見し、封じ込めることができます。
アイデンティティ攻撃が増え続ける中、アイデンティティ、エンドポイント、クラウドワークロード保護にまたがる SentinelOne の Singularity Platform は、実行時に人間および非人間のアイデンティティの両方を保護するために必要な統合コンテキストをセキュリティチームに提供します。実際の動作を見るには、ライブデモを予約してください。
よくある質問
いいえ、認証なしで認可を行うことはできません。認可は、認証されたアイデンティティに何が許可されているかを確認します。最初に相手が誰であるかを検証していなければ、権限を適用する対象のユーザーが存在しません。一部のサイトではログインなしでゲストとして閲覧できますが、それは本当の認可ではなく、単に認証されていないオープンアクセスです。重要な原則として、役割やアクセス制御を適用する前に、必ず認証を行うべきです。
OAuth 2.0 は認可のためのものです。ユーザーのパスワードを共有せずに、アプリにユーザーのリソースへの限定的なアクセスを付与します。OIDC は OAuth を基盤として構築されており、アイデンティティクレームを含む ID トークンを追加することで認証を処理します。したがって、相手が誰であるかを検証する必要がある場合は OIDC を使用します。委任されたアクセスだけが必要であれば、OAuth で十分です。両者は連携して動作しますが、役割は異なります。
役割は、ユーザーに割り当てる権限の集合です。たとえば「admin」や「viewer」があります。属性は、ユーザー、デバイス、またはセッションに関する事実であり、部門、クリアランス、場所などが該当します。認可では役割だけを確認することもできますし、属性を組み合わせてより細かな判断を行うこともできます。たとえば、役割が manager で、属性が department=sales の場合にのみアクセスを許可することができます。こうしたポリシーの設定方法は数多くあります。
SSO は一度認証を行い、そのアイデンティティを複数のアプリ間で共有しますが、各アプリは引き続き独自の認可チェックを実行します。MFA は、相手が誰であるかをどれだけ強固に証明するかを高めます。機密データへのアクセスを認可する前に MFA を要求するポリシーを構築できます。MFA に失敗した場合、認可は進行する機会すら得られません。したがって、MFA 自体が権限を付与するわけではありませんが、ログイン強度に基づいて権限付与の可否を制御できます。
認証については、ログイン成功、失敗、ロックアウト、MFA プロンプト、送信元 IP を収集してください。認可については、アクセス拒否、権限変更、役割の割り当て、権限昇格を取得してください。これらはアイデンティティプロバイダー、アプリ、セキュリティツールから取得する必要があります。これらのログがあれば、インシデントが盗まれた認証情報から始まったのか、それとも付与済み権限の悪用から始まったのかを追跡できます。明確なタイムラインの構築に役立ちます。
