条件付きアクセスでAPIアクセスを制限

皆さんこんにちは。国井です。
最近、Microsoft Defender for Endpointの運用に関するご相談をいただくことが多く、
中でもAPIを使って運用を自動化したいという話をよく聞きます。
Microsoft Defender for EndpointのAPIアクセスにはWindowsDefenderATP APIというAPIを使うのですが、これを野放図に使わせることは避けたいと思った場合、クライアントシークレットを使って制限したいと真っ先に考えると思います。しかし、クライアントシークレットは単なる文字列であり、パスワードが盗まれてOffice 365に不正アクセスに遭ったというインシデントと同じことが起こる可能性がとても高いです。
そこで今日はAPIアクセスを条件付きアクセスで制限していく方法を見てみたいと思います。

APIのアクセス許可

基本的なところのおさらいですが、APIのアクセス許可には委任されたアクセス許可とアプリケーションの許可という2種類があります。
委任されたアクセス許可はAPIアクセス時にユーザー名/パスワードを入れるパターン、アプリケーションの許可はユーザー名/パスワードを入れないでアクセスするパターンです。
どちらもよく使われますが、Microsoft Defender for Endpointの運用自動化のようなことをしたいと思ったときには通常、アプリケーションの許可を使うことと思います。そして、アプリケーションの許可でAPIアクセスを行うと、Azure ADのサインインログには[サービスプリンシパルのサインイン]という項目にログが記録されます。(なるほど、アプリケーションの許可でAPIアクセスを行う行為を「サービスプリンシパルでのサインイン」と呼ぶのですね)

条件付きアクセスでアクセス制御

[アプリケーションの許可]を利用している場合、ユーザー名/パスワードを入れないので代わりとなるセキュリティが必要になります。そこで[アプリの登録]にあるクライアントシークレットというの生成し、APIアクセス時(厳密にはトークン取得時)に一緒に提示します。
しかし繰り返しますがクライアントシークレットは単なる文字列。なのでGitHubに間違えて公開しちゃった！みたいなことがあれば一発で不正アクセスに遭います。

こうした不正アクセス対策にはいくつかの方法があると思いますが、その中のひとつに条件付きアクセスがあります。条件付きアクセスは今までAzure ADユーザーによるサインインをもとにアクセス制御をしていましたが、最近ではサービスプリンシパルを利用したサインインもアクセス制御の対象にすることができるようになっています。
設定はご覧の通り。
条件付きアクセスポリシーのユーザー選択画面で、ユーザーの代わりにワークロードIDを選択するとサービスプリンシパルを選択できます。
ちなみにサービスプリンシパルについての詳細な説明は避けますが、簡単に言うとサービスプリンシパルとはエンタープライズアプリケーションに登録されたアプリのことを指します。アプリの登録から登録されたアプリは同じ名前のアプリがエンタープライズアプリケーションにも登録されるので、それを選択します。

続いてクラウドアプリの選択ですが、
ここでは[すべてのクラウドアプリ]だけが選択対象になります。

その次に条件の選択。
条件として場所(IPアドレスの範囲)またはサービスプリンシパルリスクを選択できます。

サービスプリンシパルのリスクとはAzure AD Identity Protection (Azure AD Premium P2のサービス)で提供される、サービスプリンシパルの不正利用を検知するサービスで、
通常とは異なるアクセスパターンであったり、GitHubに掲載されているクライアントシークレットを使ってアクセスしているようなパターンであったりを検知してくれます。