イントラネットとパブリックネットワーク（インターネット）との境界をあいまいにするゼロトラストネットワークは、企業のクラウドサービス利用にも影響を与えている。テレワークによって、インターネットアクセスが業務システムにおいてもデフォルトになってきており、現状ではすべての業務システムを自社サーバールームやハウジングサービスに閉じ込めておく必然性が低下している。

コロナ禍が、企業のVPN導入やゼロトラストネットワークへの移行を余儀なくしたといっていいだろう。

ウィズコロナ時代でも、VPNやゼロトラストネットワーク導入の意味や目的、注意点は大きくは変わらない。むしろ、導入の要因や加速させたコロナ禍が、今後は非常事態ではなく定常的なものとして続くわけだ。導入時の考慮事項や周辺状況が平時の状態と取られるようになる。

自粛の解除・緩和によって、テレワークやシステムを以前の状態に戻す動きもあるが、ある程度の投資を行なって変えた、制度や組織は簡単には戻せない。オフィスを縮小した企業は、業務が回るなら改めて大きなオフィスを契約する動機は低い。会議や研修など、オンラインで問題なければ、会場確保や人員などのコストを大幅に下げることができるからだ。

ゼロトラストネットワークは、ネットワークやシステムの改修が伴う。認証を強化したり、ログ監視体制や機能を改める必要があるからだ。認証手順を追加するだけなら簡単にアドオンできそうだが、ゼロトラストネットワークでは、リスクベース認証や多要素認証のためのシステムや運用手順の変更が必要となる。動的なアクセス制御を行う必要もあるため、運用規定やポリシーの変更が必要なこともある。

そのため、ゼロトラストネットワークに対応させたシステムをもとに戻す場合、新たなシステム構築や改修のためのコストが発生する。コロナ禍によってネットワークを移行した企業でその後の運用に問題がなければ、状況が変わってもそのまま使い続けるほうが合理的である。

感染拡大や第n波のリスクがあるなら、今後のシステム設計や導入は、リモートワークやオンライン運用を定常業務に組み込んでおくべきだ。2020年から2021年にかけては、企業のパンデミック対応のためVPNやゼロトラストネットワークが注目され、各社の導入が進んだ。2022年以降は、現在の環境や状況をノーマルな状態としてメンテナンスやシステム構築を考えることになるだろう。

昨年までは、テレワーク等への対応を急いでVPNを導入したり、回線を増やしたりした企業が多いのではないだろうか。そのときにどれくらい長期的な運用を想定していたかによって、VPNの回線数や利用者アカウントの見直しが必要かもしれない。専用装置が必要なVPNでは、よりセキュアな接続に限定して利用アカウントを設定することがある。応急的な対応で設定しているなら、今後の運用に備え、アカウントの整理やアクセスするシステムリソースごとのリスク分析をやりなおしてもよい。

VPNで最も注意したいのは、セキュリティパッチだ。有名かついまだに被害報告があるのはCVE-2018-13379（Fortinet製機器の脆弱性）だ。CVE - 2019-11510（Pulse Secure製機器の脆弱性）、CVE-2019-29781（同Citrix）といった脆弱性だ。どれも対策やパッチが公開されているが、専属の管理者やIT部門の弱い中小規模の事業者が、対象機器を利用しながらセキュリティパッチなど行っていないことがある。

これらの機器を狙ったランサムウェア攻撃、サプライチェーン攻撃はいまも続いている。もし、自社が導入しているルーターやVPN装置（通常ルーター製品の機能を利用する）のベンダーや型番がわからないなら、いますぐでもシステムアセットの棚卸しをすべきだ。サプライチェーン攻撃やランサムウェア攻撃で業務停止やデータ破壊、情報漏洩といった被害を受ける企業のニュースがなくならないのは、これらネットワーク機器の管理不備が原因のひとつだといわれている。

製品によってはパッチ対応が難しい古い機器もある。そのような製品はリプレースをしたほうが早いし確実だ。

ゼロトラストネットワーク自体が、ネットワーク構成としてクラウド化やパブリックアクセスを意識した設計になるので、それ自体が次世代クラウド環境といってもいいだろう。すでに導入、運用しているなら方向性は維持したままメンテナンスやアップデートを考えていけばいい。

しかし、規模の大きい企業で、社内システムやイントラネットすべてをゼロトラストネットワーク化しているところはあまり多くないだろう。セキュリティの重要度やシステムの重要性を考慮して、ルーター（ファイアウォール）やゲートウェイで内部ネットワークとして分離している部分があるはずだ。この境界や境界防衛について、ウィズコロナが定常的になる前提での見直しは必要かもしれない。

対象リソースのリスク再評価と可用性の問題の有無などだ。クラウド利用が広がってくることで、イントラネットや保護セグメントとのやりとりで運用上の問題や使いにくさがあるなら、チェックしておきたい項目だ。可用性の問題は不正利用や運用の例外を生みやすい。改善または修正可能な問題なら対応する必要がある。

脆弱性診断や侵入テストも定期的に実施したい。専門家が必要な業務のためコストがかかる。頻繁にはできないが、攻撃状況や脆弱性情報は日々アップデートされる。業務システム側の変更がなくても診断は怠るべきではない。

SASE（サシー、セキュアアクセスサービスエッジ）もコロナ禍が背中を押した形で注目された技術だ。クラウドサービスによって業務システムなどを構築する場合、統合されたセキュリティポリシーの適用、同じレベルでのセキュリティ管理が難しいことへのソリューションとしてCASB（クラウドアクセスセキュリティブローカー）やSASEのような手法が有効とされている。

SASEでは、マルチプロバイダーのクラウドシステム構成において、セキュリティ機能やポリシー適用を統合管理するしくみだ。ユーザーから見れば、包括的なプロキシのようにも見える。

SASEは比較的新しいソリューションだが、その分機能レベルや適用範囲が定まっていない現状がある。理想は全クラウドサービスを統合できる状態だが、SASEによって対応可能なサービスやプラットフォームが限定されがちだ。この現状は2022年現在もまだ続いている。したがって、ウィズコロナかどうかという視点より、周辺技術やサービスの動向をみながら導入や検証を続けるフェーズとしてとらえたい。

注意すべき点としても、一般的なクラウドセキュリティでの視点がまず求められる。近年、クラウド環境でのセキュリティ上の課題はIAM（アイデンティティアンドアクセスマネジメント）に代表されるアクセスアカウントやクレデンシャル情報の漏洩だ。これらの情報は、クラウド環境においてスクリプトや設定ファイルに保存されることがある。通信の暗号化や鍵情報の管理に不備があると、サービスのほぼ全権が取られてしまうと思っていい。

もうひとつの注意点は、クラウド上で稼働しているシステム、サーバー、コンテナ、利用しているサービスのライブラリやモジュールの管理だ。これらの脆弱性情報の管理、対応は、オンプレミスシステム以上に重要になっている。オープンソースを利用することが多いクラウドシステムでは、構成するソフトウェア部品（モジュールやライブラリ）の把握とセキュリティアップデートが欠かせない。SBOM（ソフトウェアビルオブマテリアルズ）というソフトウェア部品表が注目されているのはこのためだ。