· 

Microsoft 365(Entra ID)のアクセス制御、設定漏れは大丈夫?

松田 幸裕 記


最近、ITユーザー企業の情報システム部門の方々とセキュリティに関する話をする割合が多くなっています。直近で立て続けに発生した大手企業のランサムウェア被害も要因になってはいますが、その前も含め徐々にセキュリティへの注目度が上がっているように思います。

ただ、どうしても「セキュリティより業務継続優先」、というか、「セキュリティを強化することで業務影響が生じ、現業部門からクレームを受けるようなことは避けたい」という意識は強く、部分的にセキュリティを緩めて設定している場面も見受けられます。セキュリティ事故の発生可能性、発生した際の影響を適切に考慮し、改めて何を優先すべきかを考えていきたいですね。

セキュリティ被害の要因として気になっているのは、SaaSやネットワーク機器などの設定不備です。EDR(Endpoint Detection and Response)やSOC(Security Operations Center)など高価な製品やサービスを導入して対策しても、設定不備があっては元も子もなくなります。総務省から昨年、「クラウドの設定ミス対策ガイドブック」も公開されていますが、それだけにこの課題の大きさを感じます。

当社ではMicrosoft 365関連で支援することが多いため、本投稿ではMicrosoft 365(Entra ID)のアクセス制御における設定不備について考えてみたいと思います。

設定漏れが生じやすい?Microsoft 365のアクセス制御

ネットワーク機器などの設計に関わったことがある人はわかると思いますが、「何を許可するか?何を拒否するか?」の制御を行ううえでは、最後の砦として「deny all(deny any)」という設定があります。管理者が何も設定していない場合、この「deny all」が有効になるため、すべての通信が拒否されます。これを起点として、管理者は許可する通信を上に(優先度高で)追加していくという流れです。

このような考え方の場合、何か設定をし忘れても最後に「deny all」があるため、セキュリティとしては安心です。基本的にアクセス制御はこのような考え方であるべきだと思うのですが、Microsoft 365のアクセス制御である「条件付きアクセス」では、少し考え方が異なります。

条件付きアクセスの場合、設定した各レコードに優先度という考え方はありません。どれか1つでも拒否されれば拒否という考え方になるため、「deny all」的なレコードを入れてしまうとそれが有効になってしまい、すべてのアクセスが拒否されてしまうのです。個人的にはこの仕様に疑問を持っていますが…だからと言って仕様が変わるわけではないため、この仕様を受け入れて「どうすればいいか?」を考えてみたいと思います。

やっぱり必要なのは「deny all」

「この人達がこのデバイスでこのサービスにアクセスしてきた場合は拒否/条件付きで許可」などのポリシーを複数設定する形にすると、設定漏れは容易に起こります。例えば、あるユーザーを作成してどのグループにも入れなかった場合、そのユーザーには条件付きアクセスポリシーが一つも適用されず、拒否もされずメールアドレスとパスワードのみでアクセス可能になってしまいます。やっぱり、「deny all」的なポリシーを作成して漏れを無くすことは必要だと思います。

ただ、単純に「deny all」のポリシーを作ってしまうと、前述したようにこれが効いてしまいすべてのアクセスが拒否されてしまいます。そのため、少し工夫が必要になります。

「対象外」を活用した「deny all」の登録を

具体的には、「対象外」の設定を使います。例えば、「PCからMicrosoft 365を利用する際、すべての人は拒否」、または「PCからMicrosoft 365を利用する際、すべての人はIntuneに登録されポリシーに準拠している必要がある」など、すべての人に適用される厳しめのポリシーを置いておきます。そのうえで、「あるグループの人たちは、社内のグローバルIPアドレスからであれば利用を許可」などのポリシーを追加すると同時に、先ほどの「deny all」的なポリシーに対し「対象外」としてそのグループを指定します。

このようにすることで、少々工夫が必要なものの、「deny all」という最後の砦がある安心感を得られる環境にすることができます。

どの製品もそうかもしれませんが、一般的に許可設定の対象は増えていく傾向があります。これは「穴が空きすぎる」という結果につながるため、セキュリティの原則である「最小権限」を意識して定期的に見直すことをお勧めします。

アクセス レビューを使用して、条件付きアクセス ポリシーから除外されているユーザーを管理する」という記事にありますが、「アクセスレビュー」という機能を用いて許可設定したグループの定期的な確認を促す機能などもあります。必要に応じて、このような機能も活用してセキュリティを強化していきたいですね。