「不正アクセス」の対策で、Azure AD認証で気をつけること
本記事は Qiita Azure Advent Calendar 2021 12/17(金)の記事として投稿します。
はじめに
パブリッククラウドの類を使うにあたって、「不正アクセス」の対策にはみなさん気を使われると思います。今回はAzure（というよりもAzure AD）において、「認証の範囲で守る」観点を２つ紹介したいと思います。
特に、そのうち２点目は盲点となってることが多く、他のクラウドサービスでは使えない機能だったりもするので、私の周りでもあまり知られていない印象です。「こういう機能があるんだ」と知っておくだけでも意味がありますのでぜひ読んでみてください。
想定されるリスクと対策
不正アクセスで一番顕著な例は「データ漏洩」かと思います。データ漏洩に対する対策としては、暗号化（データを抜かれても読めない）や、ストレージやSQLなどのPaaSをパブリックに公開しない（データにアクセスさせない）などいろいろあります。
ですが今回は「認証」、すなわちAzureADの範囲に絞って紹介します。
簡単に図示すると、下のようなアクセスパターンのうち、不正なものを弾きましょうという考え方です。
①外から中のアクセス
リスク
多くの場合、一番に思いつくのは、「外部にいる悪意のある人が、自分のAzureにアクセスしてきて、好き勝手やっていく」タイプの不正アクセスです。
データ漏洩に限らず、乗っ取られてマイニングに使われたり、踏み台としてスパムメールを撒かれたり…世の中で話題に出るのはこのパターンのアクセスかと思います。
「外部にいる悪意のある人」というのは、内部犯が正当なクレデンシャル情報を外に持ち出して、それを使ってアクセスしてくる場合も含まれます。
こういったリスクに対してはAzureAD認証を行う接続元を制限する対策が有効です。
対策
①のリスクに対しては、「条件付きアクセス」を使うことが一般的です。
条件付きアクセスの解説は、下の記事に書いたことがありますので、こちらもぜひ見てください。
今回の制御は「条件２：特定の場所からのアクセスを許可する」のところに記載している通りですが、接続元のIPアドレスを制限することで特定の場所からのみ接続可能なように制限します。
よくある構成としては、「企業の拠点ごとのグローバルIPアドレスを事前に登録しておき、それ以外からの接続を禁止」とすることが一般的かと思います。
また、つい最近まで条件付きアクセスは「ユーザープリンシパル」にしか適用できなかったのですが、11月のアップデート（プレビュー）で「サービスプリンシパル」も制御できるようになっています。こちらも検証していますので、ご参考までに。 プレビューが外れ次第、標準的な設計として取り込むべきかなと思います。
②中から外へのアクセス
リスク
続けて考えなければいけないのは、「内部にいる悪意のある人が、どこか外にアクセスして、データを持ち出す」タイプの不正アクセスです。
通常、本番環境にアクセスするような作業端末においては、プロキシ等を用いてインターネット上アクセスできる先を制限すると思います。なので、「Azure上のBLOBストレージから本番データをDLする」→「Googleドライブにアップロードしてデータを持ち出す」なんていう経路は潰していると思います。
ただ厄介なことに、Azureにおいては、Azureに接続するためのURLが"portal.azure.com"に代表されるように、AzureADテナントやサブスクリプションによらず共通のものになっています。
そのため、「本番システムA＠Azure上のBLOBストレージから本番データをDLする」→「開発者個人のAzureにアクセスしてデータをアップロード」なんていう情報漏洩の経路を考えると、「正規の通信要件」が「不正な通信経路」と同等になってしまい、制御することができません。
※厳密にいえばBLOBストレージのURIは、ストレージアカウント名が入るので制御可能です。ですが、ストレージアカウントを作成し直すためにProxyもメンテナンスと考えると、現実的に運用していくのは厳しい…
対策
このような場合に効力を発揮するのが「テナント制限」という設定です。
Azureでは、Azure AD向けの通信に特定のヘッダを挿入することで、認証を受けられるAzureADテナントを制限することが可能です。
Restrict-Access-To-Tenants: <permitted tenant list>
Azure ADでは、通信に上記のヘッダが挿入されている場合、「permitted tenant list」に記載されていないテナントの認証を拒絶する制御が入ります。このリストに記載されていないAzure ADテナントでサインインしようとすると、下記のようなエラー画面となり失敗します。
この制御を入れることで、「特定のAzureにしかアクセスできない」ということを実現でき、外部へのデータ持ち出しを防止することができます。
注意点として、この方式は「AzureAD認証を特定のテナントに絞る」ものです。
穴を探してみると、例えば「ストレージアカウントに対して、SASキーなどAzure AD認証を使わない方法でデータを持ち出される場合」は防げません。
（現実的には厳しいと言いながら）上に書いたProxyの運用もやるべきなんですね…。
参考：
- サポートブログ
https://jpazureid.github.io/blog/azure-active-directory/tenant-restriction/ - 公式ドキュメント
https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/tenant-restrictions
おわりに
パブリッククラウドは、すべからくガチガチに守るべきだ！としてしまうと、開発スピードなどパブリッククラウドのメリットを損ねてしまいます。
一方でエンタープライズな環境で本番として利用するなど、大事なデータを扱う場面は増加し続けていると思います。そういった場面で使うための「ガチガチ」セキュリティ対策の知識、使うかは別として、知っておくこと自体はとても重要です。
使う場面が来たら、今回ご紹介した機能もぜひ適用してみてください。
Discussion