はじめに
「ゼロトラスト」というワードが広く認知され、多くのソリューション導入の事例も公開されています。
しかし完全なゼロトラストの実現は非常に難しく、簡単に実現できるものではありません
そのため段階的にシステムを強化していく進め方が一般的になりますが、想定した以上に導入コストがかかったり、
必要な運用人材を確保する事が出来ず、道半ばでPJが中止となった事例も報告されています。
また上記背景から「ゼロトラストの必要性は理解しているが導入を躊躇している」といった話を
ユーザ企業のご担当者様からお聞きする事もあります。
ですがゼロトラストへの対応は、待ったなしになっています。
昨今のランサムウェアやインフォスティーラー等による大規模なセキュリティインシデントの発生は、
「一たび攻撃者に狙われれば、旧式の「境界防御」をベースとしたセキュリティでは防ぐ事が出来ない」
といった認識を広めました。
またこういった背景下でゼロトラストへの対応が遅れる事は、単にセキュリティインシデント発生のリスクを
高めるだけでなく、企業としての評判を落とす可能性すらあります。
今一度ゼロトラストにおけるセキュリティリスクの全体像を把握し、「最も重要なデータはどこに存在するか」を軸に
「何から対策すべきか」または「何から対応する事が出来るのか」について、早急に取り組む必要があります。
本ブログの目的
本ブログは、「はじめに」で記載した様な「ゼロトラストの導入を躊躇している」ユーザ企業のご担当者様が、
「自社の業務・課題と照らし合わせて何から対応すべきか」を決めていく際に、その手助けとなる情報を発信する事を
目的としています。
そのために、連載の中で以下を投稿していく予定です。
・ゼロトラスト時代のセキュリティリスク
・ゼロトラストにて実装すべきセキュリティ機能
・ゼロトラスト導入に向けた準備
・ゼロトラストのソリューションの紹介
・ゼロトラストのソリューション導入のオススメの順番
・ゼロトラストの各ソリューションで得られる効果と導入のポイント
また以下の様な最新のセキュリティトピックも、追って可能な限り投稿して行きたいと思います。
・AIセキュリティの現状
・PQC(耐量子計算機暗号)の発展
・パスキーの実装
ご承知頂きたい点
本ブログの前提条件として以下をご承知おき下さい。
- 新たな脅威の出現とその対応により、ゼロトラストは日々進歩しています。
ゼロトラストの解釈等において、執筆者と読者の方との間に相違がありました場合はご容赦下さい - 具体的なソリューションについてコメントする場合は常に最新の情報を参照する様に注意しますが、
記載されている情報が古い場合は、最新情報については適宜ご確認をお願い致します。
第1回:ゼロトラスト時代のセキュリティリスク
第1回では、旧来のネットワークベースの「境界防御」から変化したセキュリティリスクについて投稿します。
ゼロトラストでは、よく「全てを信用しない」というキーワードを耳にしますが、
これだけでは具体的に何を軸に考えていけば良いかのかが、良く分かりません。
そこでまずは、ゼロトラスト時代になり直面するセキュリティリスクの考え方がどう変化したのかについて、
投稿したいと思います。
① アタックサーフェスが至る所に存在する
アタックサーフェスとは「攻撃者から見てサイバー攻撃の対象となるユーザインタフェース」全般を指しています。
境界防御の時代ではDC及び自社拠点を信頼されたゾーンと考え、アタックサーフェスは主にインターネットとの
接続点を示す事が多いのが実情でした。
しかしゼロトラストを前提とする今のシステムは、以下理由により「アタックサーフェス」が至る所に存在します。
- 社内アプリケーションはオンプレミスとパブリッククラウドの両方に存在する
- 業務では部門毎にSaaS利用が拡大している
- 出社とテレワークのハイブリッド勤務が広く浸透して来ている
- サプライチェーン構築のため協力会社も自社のシステムにアクセスする
前述しました「全てを信用しない」というキーワードのアタックサーフェスにおける意味を考えると、
「システム上のあらゆる場所が攻撃対象となり得る」という事になります。
そして自社システムのどこにアタックサーフェスが存在するか把握し、その攻撃ポイント毎に必要なセキュリティ対策を
施す事は非常に大変な作業です。
図1:アタックサーフェスの変化
② IPアドレスからユーザID/デバイス情報を元にしたアクセス制御へ
境界防御ではトラフィックの検査対象は主にIPアドレスであり、トラフィック検査・フィルタリングを担うのは
ファイアウォールやネットワーク機器のアクセスリストでした。
しかし一たび業務端末がマルウェアに感染すると、攻撃者により外部にデータが送信されたり更なる攻撃の
踏み台にされても、ログ上からは不正通信と見抜く事は難しくなります。
そのためIPアドレス情報をベースとしたアクセス制御への過度な信頼は危険です。
ゼロトラストでは、可能な限り全てのアクセス要求に対してIDを検証し、またデバイスのセキュリティパッチなどの
状態を確認して厳密なアクセス制御を実施する必要があります。
「全てを信用しない」の本項番での意味は「通信のIPアドレスを信用せず常にユーザID・デバイスを検証する」になります。
図2:IDとデバイスの検証例
③ 常に一定の侵害を前提としてプロアクティブに対応する
境界防御からゼロトラストになり最も変化の大きい考え方かと思います。
公開されているランサムウェアの被害レポートを見ると、攻撃者が最初にターゲットユーザのシステムに侵入してから
サーバの暗号化など重大なインシデントの発生までには、一定の期間があります。
もし初期の攻撃段階で気づき必要な対策を講じておけば、後続の被害を防ぐ事が出来ます。
攻撃手法が高度化した今では、常にシステムは一定の侵害を受けている事を前提として、不正と思われるアクティビティを
早期に検知し重大なインシデントにつながる事を防ぐ事が必要になります。
「全てを信用しない」の本項番での意味は「一見問題が無さそうであっても、常にシステムは一定の侵害を既に
受けていると考え対策する」になります。
図3:攻撃の初期段階のアクティビティ
■新たなセキュリティリスク
前述したセキュリティリスクの考え方の変化により、ゼロトラストでは「境界防御」時代にはなかった新たな
セキュリティリスクが現れました。図4では、ゼロトラスト時代における主なセキュリティリスクを示しています。
図4:ゼロトラスト時代のセキュリティリスク
① 拠点PC
数の面から最大のアタックサーフェスである拠点PCは、常に優先的に対応が必要なセキュリティリスクです。
感染PCからデータが流出するだけでなく、遠隔操作により更なる侵入の起点になったりマルウェアの拡散元に
利用されることもあります。
また最近ではインフォスティーラー(情報窃取マルウェア)によって、不正に資金が引き出されたり
証券が勝手に売買されたりといったダイレクトな金銭被害も発生しています。
②在宅勤務PC
在宅勤務PCでは、共有Wifi経由でセキュリティの甘い家族PCからマルウェアに感染リスクがあります。
感染した在宅PCから社内システムにアクセスする事で、更に感染が拡大する事が懸念されます。
③DC
DCでは前述した様に、DBなど最重要なデータが侵害される前に、初期攻撃の痕跡を検知して対応する
必要があります。実害が無いという理由で本来想定されていない不信な動作のログをスルーすると、
重大インシデントにつながるリスクがあります。
④拠点
本社では特に、ランサムウェア等のインシデントが発生した場合の復旧対策を作成しておかないと、
いざ被害にあった場合に業務復旧までに長時間を要するリスクがあります。
対策はバックアップからの復旧手順、相談先のベンダーリスト、保険加入の検討などシステムの話に留まりません。
⑤社内業務クラウド(IaaS,PaaS)
社内業務で利用するパブリッククラウドでは、誤設定によるS3バケットの外部への公開や、リソースの不正利用の
リスクが有名です。パブリッククラウドでは柔軟に細かいアクセス設定ができる反面複雑になりやすく、設定不備が
発生しやすい面があります。
⑥クラウドサービス(SaaS)
複数のSaaS利用が広まる事でパスワードの使い回しが増え、1つのサービスでの認証情報の漏洩が複数のサービスへの
アクセスを攻撃者に許してしまうリスクがあります。
また部門毎に利用するSaaSが異なる事でシャドーIT化しやすく、管理者がデータ漏洩に気づきにくい点も問題です。
⑦Webサイト
依然としてフィッシング詐欺による認証情報の入手や、古いブラウザやプラグインの脆弱性をついてマルウェアを
自動的にダウンロードさせるといったサイトの存在が大きなリスクとなります。
⑧協力会社
サプライチェーンの中で、協力会社のサーバや端末から自社のシステムへ一定のアクセスを許可しているケースは
少なくなく、自社の統制が効かない協力会社のサーバ等を経由してシステム侵害を受けるリスクがあります。
最後に
Re:Qでは、ゼロトラストを実現していくための「Palo Alto FW」や「Prisma Access」の導入実績もございますので、
気軽にお問い合わせ下さい。
次回は今回記載したセキュリティリスクに対して、実装すべきセキュリティ機能について投稿したいと思います。