この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ども、ゲストのソラコム大瀧です。
BeyondCorp Remote Accessを支える技術シリーズと題して、Googleが提唱するBeyondCorp Remote Accessの関連サービスをご紹介しています。第1回はオンプレミスやクラウド環境で実行されるWebアプリケーションを保護するCloud IAP connectorについてでした。第2回は、セキュリティ機能としてCloud IAPに付与して利用するContext-Aware Accessをご紹介します。
Context-Aware Accessとは
Context-Aware Access(以下CAA)はG SuiteアプリケーションとGCP Cloud IAP(Identity-Aware Proxy)を対象とするセキュリティ機能です。Google IdP(G Suite/Cloud Identity)によって認証されたユーザーアカウントに対して、クライアントデバイスのOSバージョンやアクセス元IPアドレスなどの属性をアクセス可否の判断条件に追加します。IAPがクライアントの身元(Identity)を評価(Aware)する機能をもつプロキシなのに対して、CAAはクライアントの関連情報(Context)を評価(Aware)する機能を持つわけです。
属性というと、最近AWSのEC2 Instance Connectがサポートした属性ベースアクセスコントロール(ABAC)を連想しますが、AWSのABACはアクセスするターゲットの属性で制御するのに対して、CAAはアクセス元のユーザー属性を制御するABACの一種、と分類することもできます。
以下のライセンスで利用できます。
- G Suite Enterprise
- G Suite Enterprise for Education
- Google Drive Enterprise
- Cloud Identity Premium
今回はCloud Identity Premiumで試してみました。
ポリシーとアクセスレベル
CAAに設定できる条件の各項目をポリシーと呼び、ポリシーを組み合わせるアクセスレベルという単位で割り当てます。ポリシーにはネットワークポリシーとデバイスポリシーがあり、アクセスレベルにはそれらの真偽とand/orを組み合わせる形になります。ネットワークポリシーはIPアドレスや地域、デバイスポリシーはOSの種別、バージョンや画面ロック設定の有無などが指定できます。
Chrome Endpoint Verification
デバイスポリシーはデバイスの情報を条件にするために、ChromeブラウザかつEndpoint VerificationというExtensionのインストールが必須要件になっています。Endpoint VerificationがサポートするのはWindows、macOS、Chrome OSなのでモバイルデバイスには適用できません。しかしながらGCP Context Access Managerの画面にはデバイスポリシーのOS一覧にベータ扱いでiOSとAndroidの選択肢も表示されるので今後の拡充に期待です(それらに関するドキュメントが見当たらず、試してみましたがアクセス拒否の振る舞いしか確認できませんでした)。
リモートアクセスのシナリオでやってみた
では、リモートアクセス用途で想定されるポリシーの組み合わせおよびアクセスレベルを考えてみましょう。リモートアクセスで利用する家庭の光回線はグローバルIPアドレスが動的であり、かつ社員1人ずつが異なる回線からアクセスして来るので、ネットワークポリシーによる制限はあまり効果が期待できません。ちなみにSORACOM AirではVPG固定IPアドレスオプションという機能で3G/LTE回線からの送信元グローバルIPアドレスを固定することができ、このネットワークポリシーにうってつけです(宣伝終わり)。
次にデバイスポリシーは、様々なデバイス構成の条件を課すことができます。自宅作業では持ち運び時を想定した画面ロックやストレージ暗号化の優先度は下がる一方、OSの古いバージョンを拒否したり、会社所有/管理者の承認といったG Suiteのデバイス管理機能を強制できるのはマッチしそうです。デバイスポリシーを適用するためにEndpoint Verificationのインストールを促す仕組みもいくつかあります。今回は以下の要件で試してみます。
- アクセスレベル名: wfh
- 設定するポリシー: デバイスポリシー - macOSのポリシー 10.14.7 (Catalina以降のみアクセス許可)
設定画面はCAAの設定対象(G Suite or Cloud IAP)によって異なるため、それぞれの様子をご紹介します。
G Suiteアプリに割り当てる
Google管理コンソールにアクセスし、[セキュリティ]の項目内に[コンテキストアウェアアクセス]があります。まずはアクセスレベルを作成しましょう。画面右側の項目から[アクセスレベル]をクリックし[新しいアクセスレベルを作成]リンクをクリックします。
[タイトル]にアクセスレベル名を入力(今回はwfh(Work From Home))し[続行]をクリックします。
続いてアクセスレベルに含めるポリシーの設定画面に遷移します。
今回はmacOSの最小バージョンを10.14.7にするのでスクロールしてmacOSのポリシーに入力し、[アクセスレベルの作成]ボタンをクリックします。
続いてG Suiteアプリケーションにアクセスレベルを割り当てるために[アプリの割り当てに移動]ボタンをクリックします。
G Suiteのアプリ一覧が表示されます。今回はGoogle Keepに設定してみます。Keepの行にマウスオーバーすると右側に[割り当て]リンクが現れるのでクリックします。
アクセスレベルの選択ダイアログが表示されるので、先ほど作成した[wfh]のチェックをオンにし、[保存]をクリックします。
これで設定は完了です。Endpoint VerificationをインストールしたChrome WebブラウザにG Suite組織部門のアカウントでログインしGoogle Keepにアクセスしてみると...
今回試しているMacbookはバージョン10.14.6(Mojave)なのでアクセスが拒否されました。CAAが適切に動作していることがわかりますね。
Google管理コンソールに戻り、[レポート] - [監査ログ] - [コンテキストアウェアアクセス]を選択するとアクセスが拒否された様子がログでも確認できます。
また、[セキュリティ] - [コンテキストアウェアアクセス]の[ユーザーへのメッセージ]でアクセス拒否時のカスタムメッセージを設定することもできます。
Google管理コンソールでの設定は、直感的に操作できて良いですね。
Cloud IAPに割り当てる
続いて、Cloud IAPにCAAを設定してみます。こちらはGCP管理コンソールの[セキュリティ]にある[Access Context Manager]という画面で行います。通常のGCPサービスはプロジェクト単位で設定しますが、G Suiteの組織単位での設定になるため、最初に組織を選択します。
CAAの設定はG SuiteとGCPで共通のため、先ほど作成したアクセスレベル wfh がこちらの画面でも確認できます。
Cloud IAPのロールの設定画面にAccess Context Managerのアクセスレベルを割り当てる箇所があり、ここでアクセスレベルwfhを選択すればOKです。
Cloud IAPでの監査ログは、こちらの手順で有効化しログビューワで見る形のようです(動作未確認)
まとめ
BeyondCorp Remote Accessを支える技術としてGoogleが提供するContext-Aware Accessを試してみました。
で、全てのG Suiteユーザーにお奨めするとかEnterpriseに上げましょう！とか諸手を上げて言えるかというと、名前の通りいろんなコンテキストが絡む感じで、条件が合えばくらいに見ていただくのが良いかなと思いました。組織の部門単位での詳細な割り当てとG SuiteとGCPでの横断的なアクセスレベルと柔軟に設定できる一方で、アクセス保護自体は他のエディションでも利用できるデバイス管理側に任せることもできるのでやはり名前の通りエンタープライズな大きめの組織に導入するケースがマッチするのかなと思いました。Cloud Identity Premiumは多少値頃感があるので、他のオフィススイートを使いつつGoogleのIdPも上手く使いたい、といったユースケースがあるかもしれません。
11
