はじめに - Azure ADによるアプリケーション管理 -
アプリケーションがあふれる社会におけるセキュリティ課題
昨今、企業では、就業管理や経費精算、コミュニケーションツールなど様々なアプリケーション（以下アプリ）が利用されており、クラウド型を中心に種類も多様化してきています。便利になった一方で、利用するアプリが増加したことによって、以下の課題が浮き彫りとなってきたのではないでしょうか。
- ユーザはアプリ毎に登録したパスワードを管理する必要がある。
- アプリ毎に適用できるアクセス制御が異なるため、企業のセキュリティポリシーが統一できない。
- サードパーティのアプリを利用する際に、アプリが自社のリソースにアクセスする権限を制限する必要がある。
Azure ADによって実現できる利便性とセキュリティの両立
これらの課題を解決する一つの方法は、アプリを、Microsoftが提供するAzure Active Directory（以下 Azure AD）と統合することです。Azure ADとアプリを統合することで、浮き彫りとなった課題に対して以下のような対策を実施できます。
- シングルサインオンを実装することにより、1回の認証で様々なアプリにアクセスできる。
- Azure AD上で実行したIDの操作（作成・編集・削除）を、統合したアプリ上のIDに反映できる。
- 統合したアプリへのアクセスをAzure ADのポリシーで制御できる。
- Azure ADのユーザがアプリの求めるアクセス権に同意することで、同意したアクセス権の範囲でアプリがOneDrive上のファイルやOutlook上のメールなどの自分のリソースにアクセスできる。
クラウドアプリのフィッシングIllicit Consent Grant攻撃とは？
Illicit Consent Grant攻撃とは？
- 攻撃者は、被害者にアクセス権を要求するアプリを自身のAzure ADに登録します。
- 攻撃者は、攻撃の対象となる被害者に対してアプリの認証リンクを送信します。
- 認証リンクをクリックした被害者にアプリからのアクセス権要求を同意させます。
- 被害者がアクセス権要求を同意したことにより、攻撃者は被害者のアクセス権を取得します。
- 攻撃者は、取得したアクセス権を用いて被害者が持つリソースにアクセスします。
Azure ADに登録したアプリから要求されるアクセス権にユーザが同意すれば、アプリはユーザが持つリソースにアクセスできます。この仕様を悪用したフィッシング攻撃の一種にIllicit Consent Grant攻撃があります。Illicit Consent Grant攻撃はアプリから要求されるアクセス権をユーザに同意させることによって、攻撃者がユーザの持つリソースを盗む攻撃です。Illicit Consent Grant攻撃の主な攻撃手法は以下の通りです。
Illicit Consent Grant攻撃では、主に以下のアクセス権を被害者に要求することで、ユーザの持つ情報へのアクセスを試みます。
- Mail.Read（メールの読み取り権限）
- Notes.Read.All（OneNoteで作成したノートの読み取り権限）
- Files.ReadWrite.All（ファイルの読み書き権限）
Illicit Consent Grant攻撃はなぜ脅威なのか
Illicit Consent Grant攻撃が脅威とされる主な理由として、以下の点が挙げられます。
- 被害者が攻撃に引っかかりやすい
Illicit Consent Grant攻撃は、アプリからのアクセス権を被害者に同意させるだけで攻撃が成立します。また、攻撃者はIllicit Consent Grant攻撃に用いるアプリの名前や発行元などを偽装するため、被害者はIllicit Consent Grant攻撃に用いるアプリと気づかずに、要求されたアクセス権に同意してしまう可能性があります。 - パスワード認証やMFA（多要素認証）では攻撃を防げない
Illicit Consent Grant攻撃では、同意した被害者のアクセス権を利用して被害者のリソースにアクセスするため、攻撃時にパスワード認証やMFAを必要としません。そのため、ユーザカウントのパスワードリセットやMFA認証を設定してもIllicit Consent Grant攻撃を防ぐことができません。
Azure ADにおけるIllicit Consent Grant攻撃への予防
Azure ADではIllicit Consent Grant攻撃を防ぐための機能が用意されています。これらの機能を利用することで、危険なアプリから要求される高いアクセス権に対してユーザの同意を制限したり、管理者の同意を必須にしたりすることができます。
アプリに対するユーザの同意を制限する
危険なアプリから要求されるアクセス権にユーザが同意することを極力防ぐために、MicrosoftはAzure ADの「アプリケーションに対するユーザの同意」について、「確認済みの発行元からのアプリに対して選択されたアクセス許可を与えることへのユーザの同意を許可する」に設定することを推奨しています。本機能を利用すると、ユーザは信頼できる開発元によって発行されたアプリからの要求に対して「低影響」と分類されたアクセス権にのみ同意できるようになります。
リスクに基づくステップアップ同意を有効にする
また、「リスクに基づくステップアップ同意」を有効化すると、ユーザはAzure ADによって危険であると判定されたアプリから要求されるアクセス権に同意できなくなり、代わりに管理者による同意が必要になります。例えば、高いアクセス権の許可を要求するアプリや、発行元が確認されていない新しく登録されたマルチテナントアプリなどの場合、そのアプリは危険であると見なされて、管理者による同意が必要になります。
Illicit Consent Grant攻撃を検出するには？
Azure ADの機能によって、Illicit Consent Grant攻撃は成立しにくくなりました。しかし、管理者が誤って高いアクセス権の要求に同意してしまった場合、Illicit Consent Grant攻撃は成功してしまいます。
攻撃による影響を軽減するためには、攻撃が成功してしまったことを検知してアプリを削除することが重要です。検知の例として、Illicit Consent Grant攻撃のように高いアクセス権を要求するアプリを管理者が同意してしまった際に、Azure Sentinelによって管理者にセキュリティアラートを通知する方法を紹介します。
Azure Sentinelを用いた高いアクセス権要求に対する同意の検知
Azure SentinelはMicrosoftが提供するクラウドベースのSIEM（Security Information & Event Management）ソリューションです。様々なセキュリティソリューションから出力されるログを収集して、セキュリティに関する脅威がないかを相関分析できます。
Azure Sentinelには、カスタム分析ルールと呼ばれるKustoクエリ言語（KQL）で記載した特定の条件と一致するログを、セキュリティアラートとして管理者に通知できる機能があります。例えば、Illicit Consent Grant攻撃の痕跡を検出するために、以下の条件と一致するAzure ADの監査ログをセキュリティアラートとして通知するルールを作成できます。
- 監査ログのオペレーション名が”Consent to application”（アプリの同意）である。
- "Mail.Read", "MailboxSettings.ReadWrite", "Notes.Read.All", "User.Read", "Mail.Send", "Files.ReadWrite.All"のいずれかのアクセス権をアプリが要求している。
実際に作成したKQLのルールを以下に示します。
//(1)監査ログから検出するアクセス権をDetectPermissionsで指定する
let DetectPermissions = dynamic(["Mail.Read", "MailboxSettings.ReadWrite", "Notes.Read.All", "User.Read", "Mail.Send", "Files.ReadWrite.All"]);
//(2)監査ログから、オペレーション名がアプリの同意(Consent to application)であり、かつ
//DetectPermissions内のアクセス権を要求するログを検出する。
AuditLogs
| where OperationName == "Consent to application"
| extend a = TargetResources[0]["modifiedProperties"][4]["newValue"]
| parse a with * "[[" a_data "]];" *
| extend b = split(a_data, ", ")
| parse b[5] with "Scope: " b_data
| extend PermissionScope = split(b_data, " ")
| mv-expand PermissionScope
| where PermissionScope in (DetectPermissions)
実際に弊社の検証環境で高いアクセス権を要求するアプリに同意したところ、上記のカスタム分析ルールによってIllicit Consent Grant攻撃の痕跡を検知できました。下図のように、Azure Sentinelのインシデント画面にセキュリティアラート「Detect Consent Application with High Permissions」が生成されました。
最後に
本記事では、Azure ADとアプリを統合する利点を悪用したIllicit Consent Grant攻撃の脅威に対する予防方法・検知方法についてご紹介しました。本記事で紹介した方法はあくまで一例ですが、新たなセキュリティの脅威に対してどのように予防するのかだけではなく、どのように脅威を迅速に検出して対応するのかといった観点も企業のセキュリティを守るためには必要不可欠です。
三井情報では、本記事でご紹介したAzure ADやAzure Sentinel以外にも、様々なセキュリティソリューションをどのように活用して新たな脅威を予防、検出するかについて検証しています。これからも当社で蓄積されたナレッジとセキュリティソリューションを最大限に活用して、お客様が抱えるセキュリティ課題の解決に尽力します。
関連ページ
おすすめコラム：
ゼロトラストセキュリティって？考え方や導入時の2つのポイントを解説
パスワードにはうんざりです
関連ソリューション：
三井情報のセキュリティソリューション
森島 葵
次世代基盤第二技術部 第二技術室
現在、Microsoft 365 Defenderなどのセキュリティソリューションの評価、導入支援に従事。
コラム本文内に記載されている社名・商品名は、各社の商標または登録商標です。 本文および図表中では商標マークは明記していない場合があります。 当社の公式な発表・見解の発信は、当社ウェブサイト、プレスリリースなどで行っており、当社又は当社社員が本コラムで発信する情報は必ずしも当社の公式発表及び見解を表すものではありません。 また、本コラムのすべての内容は作成日時点でのものであり、予告なく変更される場合があります。
