適用方針

ゼロトラストアーキテクチャ適用において必要となる６つの適用方針を以下に示す。

リソースを識別し、特定できる状態にする

リソースを正確に特定できる状態でなければ、アクセス制御ポリシーの評価対象とすることはできない。そのため、リソースが識別できる状態で登録されていることが重要である。リソースは以下のものが考えられる。

  • アカウント 　従業員に限らず、外部協力者など組織内業務に関連するあらゆるユーザのアカウントや、ディレクトリサービス上のオブジェクト。RPAなどにも利用されるシステムアカウントも含まれる。

  • デバイス

スマートフォンやタブレットなど様々な種類の端末に加え、業務利用を許された個人端末が想定される。

  • サービス

オンプレミスなデータセンターやクラウドといった場所を問わず、ユーザが業務で利活用するアプリケーション等。

  • データ

デバイスやサービスに紐づくユーザが利活用するデータ。

リソースは組織内のみでなく、クラウド上や各従業員の自宅等様々な場所に存在することが想定される。また組織によっては個人所有のデバイスを業務利用として許可する事例もある。これらのリソースを全て手動で把握、管理することは現実的ではない。

そこで各種リソースを管理する資産管理ツールなどに登録し、ディレクトリサービス上のオブジェクトとして、ネットワークを介して管理することが考えられる。一例としては、デバイスを調達するサイトと端末管理サービスを紐付け、端末の初回起動時に自動的に資産として登録できるようにする仕組みが挙げられる。他にも、業務環境内のネットワークを対象に資産把握を目的としてスキャンをすることで、検出されたデバイスを一覧化することが考えられる。

主体の身元確認・当人認証を実施する

利用者および端末などの物理的な主体は、システムを利用する際にはデジタルなリソースとして活動しなければならない。そのため、実際にその主体がリソースに正当に紐付けられているか、利用者に関しては、「行政手続におけるオンラインによる本人確認の手法に関するガイドライン[^5]」に従って身元確認および当人認証によって確認しなければならない。

身元確認

身元確認は、主体が管理対象であることを確認する行為を指す。利用者の場合は、登録する氏名・住所・生年月日等が正しいことを確認する。また、デバイスの場合は、購入時に入手したシリアル番号や割り当てたIPアドレスなどの管理上の情報と、実際に当該デバイス上で確認できる情報を照合することが考えられる。

確認内容および手法については、業務の重要性あるいは権限によって異なる。また、身元確認を実施するタイミングは、システムへの登録時だけでなく、忘却や紛失した際などをタイミングとした認証情報の再発行などで、主体とリソースの紐付けが要求されるすべての局面に適用するべきである。

当人認証

当人認証はリソースの利用を試みる主体が身元確認によって紐付けられていることを知識（パスワード等）・所持（マイナンバーカード等）・生体（顔・指紋等）といった認証要素で確認することである。身元確認と同様に、当人認証も用途に応じた認証方法を適用するべきである。例えば、重要な権限を持つリソースへの当人認証の場合には、耐タンパー性[^6]をもつハードウェアの利用を義務化することが考えられる。あるいは特定のネットワークアドレスからのみ認証を許可することや、特定の別の主体による承認を要求することも考えられる。昨今は多要素認証の設定を推奨されることが多くなったが、当人認証の手法に係る実装のレベルは「行政手続におけるオンラインによる本人確認の手法に関するガイドライン[^7]」を参照して要件にあった認証方式を選択するべきである。

ネットワークを保護する

ゼロトラストアーキテクチャは、イントラネットを含めたネットワークを暗黙的に安全であるという前提を信用しない。そのため、ネットワークは通信経路の適切な暗号化によって安全性を確保しなければならない。具体的には、クラウド・バイ・デフォルト原則時に必ず利用されるWeb APIの安全性を確保するHTTPやDNSの暗号化などが考えられる。この際には「電子政府推奨暗号リスト[^8]」や｢TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～[^9]｣を参照し、適切な暗号技術が実装されていることを確認する。

リソースの状態を確認する

各種リソースは恒常的に安全とはいえない。適切に運用・保守されなければ、時間の経過とともに脆弱性が増え、攻撃可能な領域が広がる。また、設定ミス・構成の不備により脆弱性が生まれることも考えられる。そのため、各種リソースの状態や構成が安全か確認する必要がある。その確認作業はアクセス状態に関わらず常時実施されることが望ましい。何らかの手段によって、ログイン中のセッションを不正に利用されることもありうるからである。各種リソースの構成状態を確認するには、リソースの属性から総合的に診断することが重要である。具体的な属性例については以下に記す。

  • ユーザの属性情報

  • 当人認証に利用した認証要素

  • デバイスのOSやミドルウェアのバージョン

  • デバイスの構成情報

  • サービスへの入力値

  • アクセス時の位置情報

アクセス制御ポリシーで評価し、アクセス管理をする

各種リソース同士でアクセスを確立する際に、その可否を事前に定めたアクセス制御ポリシーを基にアクセス制御管理機能が評価し、その結果を施行できるようにしなければならない。また、ポリシーはその評価に応じて、別のアクセス制御ポリシーを呼び出す等、続くアクションを決定できるようにしなければならない。例えば、ある利用者のログインが普段とは大きく異なる位置情報から試行されている場合に追加の当人認証を求めるといったことが考えられる。また、アクセス元のデバイスの状態が身元確認済みのものであるかを確認することも考えられる。

将来的にポリシーそのものの内容を動的に変更する技術・ソリューションがリリースされることは否定できないが、一方、ポリシー自体は何かしらのガバナンス上のルールに基づいて決定されているものであるため、機械的に決定されたポリシーに対して説明責任を果たせる想定する必要がある。

リソースとアクセスを観測する

運用・保守をし、システムの信頼性を高めるうえで、リソースとアクセスのログの取得、アラートの通知など、政府情報システムを観測することが重要である。主な観測の目的は、次の事項の達成である。

  • 導入したソリューション上での不具合やパフォーマンス上の問題追跡

  • サブジェクト・オブジェクトの分析

  • 変更内容などの追跡・管理

  • 不審なアクセスの発見・調査

  • 監査

全てを観測することはコストに上限があることから実現可能ではない。そのため、対象を観測することによって達成したい目的がなにか、明確にする必要がある。また、観測の要件を定め、リアルタイムで見るべき内容とリアルタイムではないが定常的な確認が求められる内容、ログを残しておくだけで充足する等、目的に応じた必要十分な観測をすることが求められる。

もし、不審なアクセスが認められた際は、組織内外のSecurity Operation Center（以下、「SOC」という。）チームと共同して対処することが求められる。その場合はログの連携をするか、個々のソリューション上のダッシュボードを通して双方が監視するなど、幾つかの手法が考えられる。