Office 365でADFSを利用するとActive Directoryのグループをベースとしたアクセス制御を実装することができます。

Microsoftのサイトなどに設定例などがいくつか記載されておりますが、今回、主に大規模な組織でこのルールを運用する場合、こちらのサンプルをそのまま利用すると一部書式の問題でセキュリティリスクに繋がると考えられる物があるためこちらで共有します。

クライアントの場所に基づいた Office 365 サービスに対するアクセスの制限
An ADFS Claims Rules Adventure

書式のサンプルは以下の通りです。グループ名ではなくSIDを利用するというのはActive Directoryなどでの管理と同じで、グループの名称を変更しても不変な値をベースとして制御しています。

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "Group SID value of allowed AD group"])

例えば、以下のSG1というセキュリティグループでアクセス拒否の制御をする場合は、

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-589771422-1504810464-123969929-1223"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

などとします。

ところが、ここで1点問題と考えられるのが、上記赤字で書いた部分の書式です。==は「等しい」ですが、=~は「含む」です。また、SIDはGUIDなどとは違い可変長で、末尾の数字はグループが作成される度にインクリメントされてどんどん数字が増えていきます。

つまり、グループの数がどんどん増えて行った場合、いずれはSIDが一桁上がって制御すべきグループのSIDを「含む」グループが作成される可能性があるということです。

これにより、特定グループのメンバーを拒否しようとしたら別のグループのメンバーが意図せず拒否されてしまったり、特定グループのみアクセス許可していたサービスが意図せず許可されてしまうということが起こる可能性があります。

もっとも、ユーザーが作成するグループのSIDは基本的に4桁（1100番台？）から作成されるので、これが問題になるのは5桁のSIDが作成されるような10000以上のグループがある大きな組織になりますが。

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-589771422-1504810464-123969929-1223"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

とすることにより、意図した挙動とすることができます。