はじめに
今年（2024年）、コンテキストアウェアアクセスを実装しました。事例がまだ少ないためか関連情報があまりなく苦労しました。今後、再度実装する際に困らないように具体的なステップを備忘として記載しておきます。
- コンテキストアウェアアクセスによるアクセス制御をかけたい人
- コンテキストアウェアアクセスとは何なのかを知りたい人
そんな人たちの参考になれば幸いです。
3行にまとめると
- コンテキストアウェアアクセスは、ユーザーのデバイスや場所、セキュリティ状態に基づいてアクセス制御を行う仕組み。
- 実装には、制御対象のデバイスやアプリの選定、アクセス制限ポリシーの設定が必要。
- 実際の運用では、モニターモードで動作検証後、問題がなければアクティブモードでアクセス制限を適用し、運用を維持する。
本題
0_コンテキストアウェアアクセスとは
公式ドキュメントによると、
コンテキストアウェア アクセスを使用すると、ユーザーのデバイスが組織の IT ポリシーに準拠しているかどうかなどの状況に基づいて、そのユーザーがどのアプリにアクセスできるかを制御することが可能です。この機能を使用すると、ユーザーの ID、場所、デバイスのセキュリティ状態、IP アドレスなどの属性に基づいて、Workspace データにアクセスするアプリに対する詳細なアクセス制御ポリシーを作成できます。
とのことです。
簡単にいうと、特定条件下でないと、会社リソースにアクセスできないようにする機能です。本投稿では、そんなコンテキストアウェアアクセスを実装するまでの具体的なステップを紹介していきます。
なお、具体的な設定手順については以下サイトが参考になりますので、本投稿では省きます。
- Jamf ProとBeyondCorp Enterpriseを統合して会社のリソースへのアクセスを制御してみる
- Jamf ProとGoogle BeyondCorp Enterpriseを統合してiOSでもContext Aware Accessを使っちゃおう！
補足
・GoogleWorkspaceがIdPであり、Googleのファーストパーティーアプリ（Gmailやドライブ）以外のアプリも制御する場合を想定しています。
・具体的な仕組みについてはこちらをご参照ください。
1_制御対象（デバイス・アプリ）を決める
1-1_制御をかけるデバイスの検討
制御かけるデバイスのOSや種類（モバイル・パソコン）といった機器自体だけでなく、「誰が」「どのように」使っているデバイスを対象とするのかも検討が必要です。同じデバイスでも使われ方が大きく異なる可能性があるためです。
たとえば、工場に固定されているデバイスがある場合、個人が使用しているデバイスと同じような扱いをすべきではないケースがあります。後述する制御方法の検討にも関わるため、事前にデバイスを分類しておきましょう。具体的には以下のような観点・種類が挙げられます。
▼デバイス分類の観点例
| 項目 | 管理者 | OS | デバイス | 共有の有無 | 使用場所の変化（持ち出し）の有無 |
|---|---|---|---|---|---|
| 具体例 | 自社 | Mac | タブレット | 有 | 有 |
| 業務委託先 | Windows | スマートフォン | 無 | 無 | |
| ChromeOS | デスクトップPC | ||||
| Linux OS | ノートPC |
1-2_制御をかけるアプリの検討
業務で使用しているアプリといっても、扱われている情報・扱い方はさまざまです。以下の観点で整理しましょう。
①アクセス制御が必要か
そもそも公開情報のみ扱っているアプリであったり、マニュアルしか載っていないようなアプリの場合、アクセス制御をかける必要がないかもしれません。アプリ内で扱われている情報や、そのアプリの使用者は誰なのかを確認した上で、アクセス制御の要否を整理しましょう。
▼扱っている情報の分類例
| カテゴリ | サブカテゴリ | 内容 |
|---|---|---|
| 公開情報 | 公的情報 | 法律、行政文書、統計データ、裁判記録など、政府や公的機関が公開している情報。 |
| 公開されている個人情報 | SNSの投稿、ブログ、ウェブサイト上で公開されている個人に関連する情報。 | |
| 個人情報 | 個人情報 | 氏名、住所、電話番号、メールアドレス、ID番号など、特定の個人を識別できる情報。 |
| センシティブ情報 | 健康情報、病歴、遺伝情報、民族、宗教、思想、性的指向など、特に慎重に取り扱うべき情報。 | |
| 位置情報 | GPSデータや移動履歴など、個人の位置や行動に関する情報。 | |
| バイオメトリクス情報 | 指紋、顔認識データ、音声データ、虹彩データなど、個人を識別する生体情報。 | |
| 非公開情報 | 機密情報 | 企業の計画、製品設計、顧客データ、契約条件など、外部に公開されるべきでない情報。 |
| 事業運営情報 | 売上データ、財務データ、業務フロー、プロジェクト計画など、業務運営に関わる情報。 | |
| 顧客情報 | 顧客の連絡先、購入履歴、契約情報など。 |
▼アプリ使用者の分類例
| カテゴリ | 形態 | 特徴 |
|---|---|---|
| 社員 | 正社員 | 無期雇用、フルタイム勤務、福利厚生や解雇規制が適用される。 |
| 契約社員 | 一定期間の契約雇用。契約満了後、更新または終了がある。 | |
| パートタイム社員 | 労働時間が正社員より短い。正社員と異なる労働条件が適用される。 | |
| アルバイト | 主に短時間勤務や一時的就労が多い。学生が多く従事。 | |
| 嘱託社員 | 特定業務や退職後の再雇用を目的とする雇用形態。 | |
| 非直接雇用 | 派遣社員 | 派遣会社に雇用され、派遣先企業で働く。派遣元と派遣先の契約に基づく。 |
| 業務委託 | 個人または法人が特定業務を委託契約で請け負う。成果物や業務プロセスに基づく契約形態。 | |
| 準委任契約 | 労働力提供型の業務委託で、指示を受けながら業務を行う。 | |
| 請負契約 | 完成物や成果物に対して責任を負う業務委託契約。 | |
| フリーランス | 特定企業に所属せず、複数のクライアントと契約して働く。 | |
| 特殊形態 | インターン生 | 学生が学習や経験を目的として業務を行う。報酬がある場合とない場合がある。 |
②アクセス制御をかけても問題ないか
コミュニケーションツールは情報が集まっているため、特に制御をかけたくなりますが、その場合は不具合発生時や緊急連絡の経路を検討する必要があります。
コミュニケーションツールも制御対象として含む場合は、緊急連絡やコンテキストアウェアアクセスの不具合発生時の連絡方法を社内にしっかり周知させましょう。なお、アクセス制御対象外とする連絡経路を確保する場合は、多要素認証を必須にできるような、なりすましを防げるツールにしましょう。
③ポリシー準拠デバイスでアクセス可能か
デバイスの種類を条件に制御をかける場合、Chromeブラウザ・ファーストパーティアプリのみ制御可能であり、それ以外はポリシーに準拠したデバイスであったとしても「アクセス」できません。SAML SSOでのログイン時にSafariを必ず経由するサードパーティアプリがあった場合、ポリシーを満たしていたとしても「アクセス権がありません」と出てしまいます。
私の経験では、ジョブカン経費精算／ワークフロー、バクラク申請・経費精算は上記仕様であったため、やむなくアクセス制御の対象から外しました。
2_制御方法を決める
「デバイス」「IPアドレス」「OS」などの種類があります。デバイスによる制御が最も細かい粒度で制御できます。
特に、GoogleWorkspace標準のデバイス ポリシーよりも、Jamfと連携させてJamf側で条件を作成した方がより細かい粒度でポリシーを作成可能です。たとえば、特定アプリがインストールされたコンピュータのみが所属するスマートコンピュータグループを作成し、そのグループを準拠対象とすることができます。
制限をかける際の条件とその条件別の制限の細かな仕様をざっくり整理すると以下の通りです。
▼ポリシーの種類（参照：コンテキストアウェア アクセスでビジネスを保護する）
| 制御の種類 | 制御の詳細 | 制御をかけるために必要なソフトウェア | 制御可能なデバイス | 制御可能なOS | 制御可能なアクセス方法 |
|---|---|---|---|---|---|
| デバイス | デバイスの特性を指定。該当する特性を持つデバイスを使用するユーザーがアクセス可能。 例えば、暗号化の有無、指定OSバージョン以上など細かな条件を作成可能。 |
・パソコン:Chromeウェブブラウザ、ChromeのEndpoint Verification拡張機能が必要 ・モバイル:Googleエンドポイント管理が必要 |
デスクトップパソコン、ノートパソコン、モバイルデバイス | ・パソコン: Mac、Windows、ChromeOS、LinuxOS ・モバイル: Android、iOS ※Androidについては細かい特記事項あり |
・パソコン: Chromeブラウザ、パソコン版ドライブ ・モバイル: Chromeブラウザ、組み込みファーストパーティアプリ |
| IP | IPアドレスの範囲を指定。範囲内のIPアドレスを使用するユーザーがアプリにアクセス可能。 | エージェント不要 ※Apple Private Relay が有効になっている Safariの場合は細かい条件あり |
同上 | ・パソコン: Mac、Windows、ChromeOS、Linux OS ・モバイル: Android、iOS |
・パソコン: ウェブブラウザ、パソコン版ドライブ ・モバイル: ウェブブラウザ、組み込みファーストパーティアプリ |
| アクセス元の地域 | 国や地域を指定。指定した国・地域にいるユーザーがアプリにアクセス可能。 | 同上 | 同上 | 同上 | 同上 |
3_制御対象アプリのログイン経路を制限する
サードパーティアプリを、コンテキストアウェアアクセスによてアクセス制御する場合、カスタム SAML アプリとして登録し、SAML SSO以外でのログイン経路を塞ぐ必要があります。
3-1_GoogleWorkspaceとアプリをSAML連携させる
具体的には、Open ID Connectやそのアプリ自体の認証情報（ID・PW）によるログインなどです。アプリによってはSAML SSOを有効にするといっても細かい仕様の違いがあります。アプリを使用しているユーザに影響が出るので、以下観点を事前に確認したうえでSAML連携させていきましょう。
▼確認点
- SAML SSO・ID・PWによるログインの併用できるか
- ログイン経路のSAML SSO限定化できるか
- ユーザ単位でログイン経路を指定できるか
- SAML SSOを有効化とSAML SSO以外のログイン経路の制御を個別設定できるか
- 認証プロセスをSP側・IdP側のどちらから開始できるか
- SP側のみの場合、Googleアプリメニューに対象アプリが存在していても、そのメニューから直接SSOできません
3-2_SAML連携できないアプリの対応を検討する
SAML連携できないアプリがある場合の対応を検討しましょう。
たとえば、GoogleWorkspaceとSAML連携できるパスワード管理ツールを導入し、アプリの認証情報をそのパスワード管理ツールに保管することで、実質的にGoogleアカウントの認証を経由する必要がある状態にできます。なお、この運用にする場合は、「Chromeのパスワードマネージャ機能を使用不可」に変更し、パスワード管理ツールがないとID/PWを使えない状態にする必要があるのでご注意ください。
4_アクセス制御をかける
ここまで来れば事前準備は完了です。事前に整理した方法で、アプリにアクセルレベルを割り当てていきましょう。
4-1_モニターモードで動作検証をする
アクセスレベルを割り当てる際には、アクセスレベルをまずは「モニターモード」にすることがおすすめです。モニターモードとは、実際にはアクセスをブロックしない状態で、想定通りアクセス制御できているかを確認できるモードです。
参照：アプリにコンテキストアウェア アクセスレベルを割り当てる
なお、動作検証時の注意点が2つあります。
注意点①：「アクセス許可されたログ」は出ない
モニターモード・アクティブモードのどちらでも「アクセスブロックされたログ」は出てくるのですが、「アクセスが許可されたログ」は出てきません。そのため、アクセルレベルの調整をする際には、想定通り「準拠してない（＝アクセスブロックされるべき）デバイスからはアクセスしてブロックされる」ことをその都度確認しましょう。
注意点②：Jamf ProとGoogle BeyondCorp Enterpriseを用いたiOSデバイスの制御が不安定
私の経験母数が1社のみのため、その会社特有の事象である可能性もありますが、Jamf ProとGoogle BeyondCorp Enterpriseを用いたiOSデバイスのアクセス制御は不安定です。
というのも、以下サイトに記載のように「SelfServiceにてデバイスを登録」をしても「アクセス権がありません」と出てしまい、2-3回ほど同じ登録作業をしてようやく正常に動くケースが多かったです。
詳細を忘れてしまいましたが、SelfServiceアプリからデバイスを登録する際に、SelfServiceアプリ以外のアプリ（Gmailやサードパーティ製アプリなど）を起動したままだと、そのアプリのアクセス情報がSelfServiceアプリからのデバイス登録の情報よりも優先されてしまい、アクセスブロックを起こしてしまう、みたいな事象が起きているようでした。
根本解消ができなかったため、「SelfServiceアプリ以外は一度終了したうえで、2-3回SelfServiceアプリにてデバイス登録してください」とユーザに案内しています。
参照：Jamf ProとGoogle BeyondCorp Enterpriseを統合してiOSでもContext Aware Accessを使っちゃおう！
4-2_アクティブモードに切り替える
モニターモードで試したうえで想定通りであれば、アクセスレベルを「アクティブ」に変更し実際にアクセスブロックをかけましょう。事前にユーザにどんな動作になるのかをお知らせしておくと、混乱が生まれづらいのでおすすめです。
参照：アプリにコンテキストアウェア アクセスレベルを割り当てる
5_アクセス制御を維持する
実際に制御できたとしても維持されないと意味がありません。事前に整理した分類を維持できるように、各アプリの発行フローや入退社対応などの運用を整備したり、対応者間で共通認識を持っておけるようにしましょう。
（個人的にはこの部分が意外と難しく、まだ十分にできてないのですが。。。）
おわりに
公式ドキュメントでも全容や詳細は書いてあるのですが、サードパーティアプリを連動させる点では不十分だったので、自分なりに整理し直してみました。
細かい部分は公式ドキュメントを参照いただきつつも、実際に運用をする際の参考になれば幸いです。