Zenn
🔐

Entra IDの条件付きアクセスを改めて整備してみた（PC編）

2024/10/13に公開
IdP
Jamf Pro
Entra ID
tech

はじめに

弊社では、IdPとしてMicrosoft Entra ID (旧称 Azure Active Directory)を利用しています
IdPとは：クラウドサービスなどのアクセスに必要となる認証情報を提供する役割です

企業によっては、「Okta」だったり「HENNGE One」だったりと、いろいろ種類があります
今回はMicrosoftさんのIdPの機能である「条件付きアクセス」の機能についてのお話です

弊社の運用のお話

だいぶレアケースな運用をしていますので一部ご紹介します

  • 9割は Windowsユーザー、1割がMacユーザー
  • 従業員にEntra IDのパスワードを伝えていません
  • メインのブラウザはGoogle Chrome、Microsoft Single Sign-onの拡張機能を導入しています
  • 私物のスマートフォンにはMicrosoft Authenticatorをインストールしてらっています
  • 会社携帯は、130人ぐらい所持している

条件付きアクセスとは

いろいろ説明するのが難しいのでChatGPTちゃんに聞いてみました

あなたの家にセキュリティシステムがあって、誰でも簡単に入れるわけではありません
セキュリティシステムは、特定の条件が満たされたときだけドアを開けてくれる仕組みです

例えば、このセキュリティシステムが以下のように設定されているとします

  • 鍵を持っている人だけ
    • 家の中に入るには、事前に渡された特別な鍵を持っている人だけが入れる
  • 一定の時間帯のみ
    • ドアは夜の9時以降には閉じられるように設定されていて、その時間帯にしか開けてもらえない
  • 誰が来ているか
    • 家族や友人と認識されている人のみが入れる

このように、条件付きアクセスは「誰が」「どこで」「どのような状況で」リソースや情報にアクセスできるかを制御する方法です。デジタルの世界では、会社のデータやアプリケーションに対して同じようなルールを設定し、セキュリティを強化するために使われます。

例えば、会社のメールにアクセスするためには「企業ネットワークから接続すること」「2段階認証を通過すること」「管理者からの許可があること」など、いくつかの条件が必要になるかもしれません。これにより、会社のデータが不正アクセスから守られます。

私が入社したときの環境

そもそもEntra IDのパスワードは従業員には伝えていません
仮に私物のPCから入ろうとしても パスワードがわからない！ という状態になります

会社から渡しているPCで拡張機能がうまく動作しなかった際、サインイン画面になってしまったりと「パスワードレス認証」を使いたいなーと思っていたようです

↑この話は私の上司であるふみふみさんの記事から推測しました
（ここからはふみふみさんとの会話も入ります）
https://zenn.dev/humihumi/articles/6f25c861bfe4f4

最終的なゴール

目的なく実施しても、なにが達成できたのか考えることができません
そのため最終的な目標として、上記にもある通り 「パスワードレス認証」を展開できるようにする　という目標を掲げて取り組みました

今回はこのゴールを達成するまでの過程までお話していきます
（あくまで弊社での運用のお話になるため、参考にしてください）

実現するためにやったことその1（洗い出し）

まずは、どんなロケーション/デバイス/ユーザーがEntra IDにアクセスしているか調べてみました
Entra IDのサインインログや、デバイス情報等から調査をしていきました

  • ロケーション
    • オフィス1
    • オフィス2
    • 各従業員の自宅
    • Azure VM（Azure IaaS内）
  • デバイス
    • Android（Intune管理）
    • Android（Google エンドポイント管理）
    • Android（MDMなし）
    • iOS（Jamf Pro管理）
    • iOS（Intune管理）
    • iOS（MDMなし）
    • Windows（Intune管理）
    • Windows（MDMなし）
    • Mac（Jamf Pro管理）
  • ユーザー
    • 一般従業員
    • サービスアカウント（APIユーザーとか）
    • 共有アカウント（一時的な利用）

可視化したいので、文字だけではなくこのように図に起こしてみました（一部端折っていますが）

実現するためにやったことその2（構成設計）

次に、どんな構成にしたいのか考えました
例えば....

  • 特定のデバイスからのアクセスを拒否
  • 特定の場所からのみアクセスを許可
  • 特定のSaaSへアクセスを拒否（逆に特定のSaaSのみアクセス可能）
  • 特定のOSバージョン以下は非準拠とする（コンプライアンスポリシー)

ふみふみさんと相談して、下記で決めました

  • 特定のデバイスからのアクセスを拒否
    • 準拠済みではない端末からのアクセスを拒否（野良デバイス対策）
    • Windows/Mac/iOS/Androidが対象
  • 特定の場所からのみアクセスを許可
    • デバイス登録は、必ず会社のネットワーク環境下のみ許可
      • Windows/Macが対象
      • ゼロタッチキッティングはしていないので、普通に使っている分には問題ない
    • iOS、Androidモバイル回線を使う人もいることを想定するため対象外
  • 特定のSaaSのみモバイルからのアクセスを許可（メール系、ワークフロー系）
    • メール系・Web会議ツールは許可
    • クラウドストレージ等はブロック
    • 基本的には、Windows/Macからアクセスしてもらうためわざわざスマホで見られる必要がない
  • 特定の要件を満たさない場合は、非準拠とする
    • Windows/Mac
      • 2世代前以上のOSを利用している場合
        • 長期間利用していない人には、連絡し返却/アップデートしてもらう
      • EDRがインストールされていない場合
    • iOS
      • 2世代前以上のOSを利用している場合
      • 脱獄していないこと
      • パスコードが設定されてい
    • Android
      • 機種によって異なるため、OSバージョンの縛りはなし

これらを実化するために、ネクストアクションに行きたいと思います

実現するためにやったことその3（ポリシー設計）

構成を設計した次は、どのようなポリシーがあれば構成設計どおりに動作できるかポリシーの設計を行っていきました

弊社では下記の通りにまずはポリシーを設定していきました

番号 ポリシー名 意味 対象のOS 対象のアプリ アクセスを許可する条件 補足
1 PC-準拠済であればアクセス許可 準拠済みであればSasSへのアクセスを許可 Windows/Mac BoxとかGmail デバイスが準拠済であること 当初は無効
2 PC-特定の場所からのみEntra Join許可 指定した場所からのみEntra Joinが可能 Windows/Mac Microsoft Intune Enrollment / User registration app for Device Compliance Microsoft Intuneのドキュメント Jamf Proのドキュメント
3 PC-条件付きアクセステスト 後述するテストアプリ用 Windows/Mac SSO TEST 当初は無効

後述にも記載しますが、ポリシーを作って即座に有効にしてしまうと、業務影響が出てしまいます

また企業によっては、「すべてのクラウド アプリ」に対して設定を入れているケースもあるかと思いますがExOはSPOも意図せずブロックしてしまうケースがあるようです
https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/service-dependencies
そのため、弊社では 「すべてのクラウド アプリ」 では設定をいれず、個別のアプリケーションに対していれるように運用することとしました

以前Microsoftで実施されていたWebinar等ありますのでご参考にしてみるのもいいと思います
https://github.com/yusukekodama/PMActivities/blob/master/Webinar/Schedule.md#season-3-2019年-3月---6月実施

実現するためにやったことその4（準拠済/非準拠の構成）

上記にも記載した通り、準拠済み/非準拠と判定するロジックをいれる必要があります
準拠済み/非準拠と判定するには、MDMで提供されている機能を利用します

Jamf Proの条件付きアクセスが利用不可となるようで、デバイスコンプライアンスに移行したりと対応しました
https://it-money-life.com/jamf-pro-migration-devicecompliance/

その2（構成設計）で構成した設定をもとに、IntuneやJamf Proでポチポチ設定を入れていきました
ポリシーを配布してから、端末によっては反映に数日かかることがありますのでのんびり全端末反映まで待ちましょう
（PC起動していない人とかは、上長経由で電源入れてもらうとか行いました）

非準拠になる端末は、なにが原因で非準拠と判定されてしまうのか調査を行いました
調査する中で、特に印象に残っていることを書いていきます

  • Windows：コンプライアンスポリシーが反映されない

    • 長期的に利用していない人は、Windows Updateを実施していただきました
    • 対象者にデバイスの同期を行っていただきました
    • それでもだめな人はPCを新しいものに交換しました

  • Mac：Jamf AADのポップアップがしつこいぐらい出てくる

    • 無視されてしまうと、条件付きアクセス展開時にうまく認証できなくなってしまう
    • Intuneからデバイス情報を削除
    • Mac側もIntuneに関連するデータを削除参考
    • 画面共有などしながら、改めてデバイス登録を実施

思い返すとこのフェースが1番しんどかった気がしますが1番大切なフェースでもあります
（個別に連絡し対処してもらうとか）

実現するためにやったことその5（テスト）

「準拠済み」の台数が9割を占めてきました！

準拠済みであれば、アクセスできるようにポリシーを入れていきたいと思います
が、ただ本当にそのデバイスはブラウザで準拠済みと判定されるのかとか
いきなり業務で利用するアプリに設定してしまうと、最悪アクセスできなくなってしまい業務影響が出てしまいます
そのため、弊社では、RSA が提供している「SAML 2.0 Test Service Provider」を使用してテストを実施しました
ただ単に実施してというだけではなく、「今後どうなってしまう」とか影響を添えてあげたことで利用者にとってインパクトや重要性も伝わったかなと思っています

  1. 管理者側で、Test Service Providerが利用できるように設定する
    ・ その3（ポリシー設計）で作成したテスト用の条件付きアクセス作成したアプリを適用させます
  2. 各ユーザーのアプリパネルに、テストアプリを表示させる（弊社ではアプリ名をSSO TESTにしました）
  3. クリックしてもらい、シートに完了報告記載してもらう
  4. 完了！！管理者側でログとにらめっこしながら適切にデバイス情報が渡せているか確認

ユーザー自身10秒も確認に時間がかかりませんので、あっというまに全従業員に実施していただけました

実際にTest Service Providerをどのように設定するかは下記Zenn記事をご参考にしてもらえればと思います
https://zenn.dev/microsoft/articles/1740f5328815d6

このフェーズにおいても、ブラウザでうまくデバイス情報が渡せなかった端末などは交換を進めていきました

実現するためにやったことその6（本運用開始）

99％のPCでテストが終わることができました
次は、実際に業務で利用しているツールに対し条件付きアクセスを適用させていきます
（その3（ポリシー設計）で作成したポリシーに対し、個々のアプリを追加していきます）

いよいよ本運用に入りますので、下記のことに注意しながら追加をしていきました

  • 追加するのは業務上影響がない時間に実施すること（18:00以降とか）
  • 業務上大きく影響がないアプリケーションから追加していくこと
    • 1:社内名簿SaaSアプリケーション
    • 2:一部ユーザーのみ利用しているもの（50人未満）
    • 3:多くのユーザーが利用しているもの（全従業員ではない）
    • 4:全従業員が利用しているもの

下記のような投稿を全従業員向けに周知した上で追加を行いました

追加した後はEntra IDのサインインログを見ながら、条件付きアクセスが失敗になっていないか確認しつつそれの繰り返しでした
事前にテストをしておいたおかげで失敗になる端末はなく、準拠済み端末からのみアクセスできるようになりましたとさ

最後に

まずはPC（Windows/Mac）からのアクセスに対し条件付きアクセスを構成しセキュアな環境にすることができました
実施する中で何度も検証し、どのようにすれば安全になるのだろうと考えることができました
今回はPC編ですが、スマホ編もまだありますのでそれは別記事にしたいと思います

Discussion