境界型防御からゼロトラストへの『移行』なんてあり得ない
一般的な企業インフラのセキュリティの話。
クラウドはインターネットからのアクセスを想定しているため、今の時代ゼロトラストの実装は必然です。企業が全ての重要データをクラウドに預けているなら、ゼロトラストへの移行というのもまだ頷けます。
ですがオンプレに少しでも重要なデータが存在する一般的な企業インフラにおいては、ゼロトラスト導入よりも境界型防御とソフトウェア Version UP の運用のほうが重要です。
移行ではなく共存。境界型防御と Version UP 運用をきちんとやっている企業だけがゼロトラストの導入を検討しましょう。
なお、本記事ではゼロトラストの実装については一切触れません。
ランサムウェアの侵入口は大きく2つ
ランサムウェア被害はもはや他人事ではありません。攻撃者がどのように侵入してくるかを予測し、対策を練る必要があります。
具体的な手法については非常にバラエティに富んでいますが、大きくカテゴライズすると侵入経路は以下の 2 つです。
- インターネット公開しているサーバーを正規ルート、もしくは非正規ルートで不正アクセス
- メールの添付ファイルや拾った USB 等の不正な媒体からマルウェアに感染
一般的にはその後、(まだの場合はマルウェアを仕込み、) 攻撃者が用意した C2 (Command & Control) サーバに接続しにいき、攻撃者がリモートで不正アクセスした端末を操作できるようになります。(いわゆるバックドア。マルウェアにより端末再起動後も C2 サーバーへ接続するようになる。)
1 つ目の正規ルートとは、公開しているサーバーから見て想定通りのアクセスを指します。具体的には、不正に取得したID/パスワード情報を使ってログインされた場合などです。サーバーから見たらそれが不正なのかどうか分かりませんが、人間の世界では ID/パスワードは人間に紐づいているものであり、違う人間が使ったらそれは不正アクセスです。
非正規ルートというのはサーバーに存在する脆弱性を突いてそのプロセスを乗っ取るなど、サーバーが想定していないアクセスを指します。
2 つ目のメール添付、USB については説明は不要でしょう。
対策として、2 つ目については PC でのエンドユーザーの行動がカギを握ります。不審なメールの添付は開かない、所掌の分からない USB は繋がない、など基本動作の徹底が重要です。
一方、1 つ目についてはサーバの運用管理者がカギを握っており、できる限りのセキュリティ対策を行う、速やかにソフトウェア Version UP ができるか、異常なアクセスを検知できるか、というのが重要です。
ただ、「できる限りの」とはどの程度までやればいいのか、明確な指針はありません。ここでは、その指針の 1 つの考え方を紹介します。
インターネットからの攻撃者の侵入手口
下図は verizon 社が公開している「2023 DBIR (Data Breach Investigations Report)」の P.36 にある、基本的な Web アプリケーション攻撃の侵入手口を示した表および文言の引用になります。
上図は Verizon のレポート 2023 DBIR (Data Breach Investigations Report) P.36 より引用
https://www.verizon.com/business/resources/reports/dbir/
1 位は認証情報の不正取得がダントツです。2 位は脆弱性の探索、3 位はブルートフォース、5 位はバックドア (C2) 、6 位は SQL インジェクション、7 位はネットワークスキャン、8 位は設定ミスの探索です。
ここではこれらの攻撃への対策を考えていきます。
なお、上記は Web アプリケーションが前提ですが、以降は http(s) だけでなく全プロトコルに拡張して対策を考えます。
インターネット公開サーバーのセキュリティ対策
認証情報の不正取得への対策: 多要素認証
まずは 1 位の認証情報の不正取得への対策の定番は「多要素認証」です。インターネット公開していて、かつ、エンドユーザーに認証をさせる場合は必ず多要素認証を実装しましょう。 2 段階認証では結局認証情報を不正取得される可能性がそれなりにあるので NG です。ワンタイムパスワードや生体認証 (FIDO/FIDO2) など、インターネットからでは取得が限りなく難しい手法を使いましょう。
また、多要素認証は 3 位のブルートフォースによる認証突破後も不正アクセスを防ぐ役割もあり、さらに場合によっては 2 位の脆弱性も防御できることがあります。後者は具体的には 2020 年にダークウェブに大量の ID/パスワード情報が漏洩した FortiGate SSL-VPN の脆弱性ですが、これはディレクトリトラバーサルの脆弱性によって平文の ID/パスワードが取得できたことが大きな問題になりましたが、多要素認証を実装していれば SSL-VPN への侵入は防げたはずです。
脆弱性の探索への対策: インターネット公開サーバーのソフトウェア Version UP
2 位の脆弱性の探索については、とにかく「インターネット公開サーバーのソフトウェア Version UP の運用を厳格化する」ことです。インターネット公開しているサーバーはクリティカルな脆弱性が公開されたらすぐソフトウェア Version UP が必要です。
これは業者へ委託するしか選択肢が無い、かつ、予算の範囲内でしか動けない企業の場合は非常に厄介な問題になりますが、定期的なバージョンアップを 1 年に何回実施するか、インターネット公開サーバーについてはもしクリティカルな脆弱性が公開されたときにどう対処するか (別途契約するか、など) を事前に決めておく必要があります。
20 年前であれば「バージョンアップ起因の不具合によるサービス停止」のリスクを考慮し、バージョンアップは積極的には実施しない傾向にありましたが、ランサムウェアが蔓延る現代においてはバージョンアップしないリスクのほうが高いです。個人的な感覚では昔よりバージョンアップの不具合は減っていると思いますし、まとめてアップデートするよりこまめにアップデートするほうが不具合リスクも低いでしょう。
また、この対策に関連してですが、リモートアクセス VPN は UTM に付随する機能を使う場合がありますが、インターネットとの接続で使うようなネットワークの基幹となっている UTM にリモートアクセス VPN 機能を実装するのはお奨めできません。というのも、Version UP の際にインターネット断が発生することから、作業時間が限られるからです。緊急な案件なのに、場合によっては調整に時間がかかってしまうでしょう。さらにもし Version UP に失敗したときのことを考えると計画時間も多く取る必要があります。
ブルートフォースへの対策: 一時的なアカウントロック
3 位のブルートフォースへの対策としては「一定時間内のログイン試行回数の上限値」を定め、上限値を超えた場合は「一時的なアカウントロックする」といった対応が定番です。
特に Windows の RDP や SMB はデフォルトでは試行回数の制限はありません。設定でアカウントロックはできますので実装すべきですが、そもそも RDP や SMB, SSH といったリモート操作が可能になるプロトコルをインターネットへ公開すべきではありませんし、もっというと Windows はあまりインターネット公開に向いていません。インターネットから使いたい場合はリモートアクセス VPN 装置を経由するようにしましょう。
バックドア対策: インターネットへの通信を送信元 IP/宛先 URL の組合せで制御
5 位のバックドアについてはいわゆる出口対策が有効です。DMZ に限った話では無いですが、サーバーはインターネットへのアクセスは基本アップデート情報取得くらいなものですので、制限すべきです。具体的にはプロキシ経由にし、プロキシで「送信元 IP と宛先 URL の組み合わせ」を定義し、その組み合わせのみアクセスを許可する、というのが望ましいです。FortiGate や PaloAlto では基本ライセンスで URL へのアクセスポリシーも記載できますので、それを活用するのもよいでしょう。
ただし、宛先 URL での制御は運用でそれなりの SE レベルが必要になります。それも踏まえこの実装が難しい場合は、UTM の IPS 機能で C2 サーバへのアクセスを検知し遮断する仕組みもありますのでそれを検討します。
SQL インジェクションへの対策: プレースホルダー等アプリ側の実装で
6 位の SQL インジェクションについてはプレースホルダーの利用などが有効ですが、どちらかというとインフラよりもアプリケーションセキュリティで対応したほうが良いと思います。
インフラとしては WAF という選択肢もありますが、個人的には優先度は低めです。2021 年の Log4j の脆弱性のときは攻撃者は色々なバイパス手法で攻撃を試みており、セキュリティエンジニアがこまめに WAF のシグネチャ更新を行ったという事例があったと記憶しています。そのときのやり取りを考えると、運用負荷 + 価格コストと効果のバランスの見極めが難しい、というのが個人の感想です。
もちろん、導入して助かるケースもあるはずなので、導入不要というわけではありません。あくまで、ここで紹介している他の対策が優先、という意味です。
探索活動への対策: インターネット公開範囲をできる限り制限
7位、8位 (加えて 2 位) はいわゆる探索活動になるのですが、インターネット公開している限りはこれらを制限するのは難しいです。ですが「そのサーバーは本当に全世界への公開は必要か？」というのをもう一度確認してみることも重要です。
例えば在宅勤務が多くなってきている昨今においてのリモートアクセス VPN は、日本国内からのアクセスは想定されることが多いと思います。その場合、UTM の機能において「送信元 IP が日本の IP アドレスのみ」に制限することができます。
保守用のリモートメンテナンス用であれば、利用者の利用場所はわかっているのですから、送信元 IP アドレスを /32 単位で絞って開けるのは非常に効果的です。個人的には、ここまで限定していれば多要素認証は不要と思います。(送信元グローバルが動的 IP だと常時設定は難しいですが、クリティカルな脆弱性公開時などはいったんすべて閉じて、必要なときに誰かに依頼して開けてもらう、という運用も考えられます。)
また、リモートアクセス VPN は SSL-VPN を利用することも多いですが、個人的には IPsec や OpenVPN 等の UDP を使うサービスを好んでいます。パフォーマンスの面もありますが、公開プロキシ経由での探索ができなくなるのでセキュリティの面でも好ましいからです。(もちろん AWS 等で日本リージョンの VM からはアクセスできるので完璧ではないですが、攻撃者の攻撃コストを高めるという点で効果がある。)
侵入されることも想定したセキュリティ対策
侵入されたからと言って必ずしも被害にあうかというと、そういうわけでもありません。侵入後、社内ネットワークを探索する必要があるからです。侵入したサーバー/PC に重要な情報があるとも限りません。
攻撃者は 1 つの端末を掌握した後は他の端末にも横展開 (ラテラル・ムーブメント) して掌握範囲を拡大していきます。
なので攻撃者に好き勝手にさせないためにも内部のセキュリティも蔑ろにしてはなりません。
PC, 内部サーバーのソフトウェア Version UP
DMZ のサーバのソフトウェア Version UP は必須と言ってもいいくらいですが、PC や内部サーバはしなくてよいかというとそういうわけではありません。Version UP を実施すれば攻撃が成功する可能性を確実に低くすることができます。
かといって DMZ と同じレベルで実施するのも難しいですので、DMZ のような緊急対応は諦め、定期的なVersion UP (できれば月 1 回、最低でも年 1 回) にするのが現実的でしょう。
DMZ 構成の適正化
稀に DMZ の作り方を間違えているケースに出くわします。DMZ のサーバーから内部ネットワークへアクセスする際に、FW を経由させるのが正しい構成なのですが、そうなっていない場合、DMZ の意義が大きく薄れることがあります。
上図のように改善点①を実施し FW で通信制御するか、もしくは改善点②を実施しコアスイッチにて DMZ から他の内部ネットワークへの通信を必要最低限に絞る必要があります。
同セグの通信防御
同セグメントについてはどうやっても FW を経由できません。一般的な手法としては Windows Firewall や Linux の firewalld 等の端末の FW 機能で同セグからの RDP, SMB, SSH, WinRM, MS-RPC 等を不許可にするのがよいでしょう。RDP, SSH については基本的に「管理者セグメント」を定めて、そのセグメントからのみ許可するのが望ましいです。
SELinux (オプション)
インターネット公開しているサーバが RedHat 系 の Linux なら SELinux を使うのは大きな武器です。非正規ルートでの不正アクセスの場合、未知の脆弱性であっても対応できる可能性が高いです。
SELinux はデフォルトの enforcing だと予期せぬトラブルに繋がることがありますが、permissive モードにしておけば通常のサービスの妨害はしないので安全です。不正な行動をしたプロセスを audit.log に記録します。
ただし、permissive については設定するだけではダメで、audit.log で SELinux の検知ログが出ていないかを確認し、無害なものか有害なものかを判別する必要があります。
SELinux の概要については以下をご参照ください。
なお、発展的な構成として構築の手間はかかりますが、Zabbix で audit.log を監視するなどすれば、検知の自動化も可能です。
対策のまとめ
- まずはソフトウェア Version UP を確実に運用する (DMZ だけでなく内部サーバーや PC も対象)
- インターネット公開かつ認証が必要なサーバーについては多要素認証を実装する
- VPN 装置はネットワークの基幹となる UTM には実装しない
- ブルートフォース対策として試行回数に応じた一時的なアカウントロックを有効化する
- RDP や SMB, SSH 等のプロトコルはインターネット公開しない (リモートアクセス VPN 経由で利用する)
- サーバーからインターネットへのアクセスは送信元 IP, 宛先 URL の組合せレベルで制限する (それが難しいなら UTM の IPS による C2 サーバへの通信防御を検討する)
- 可能ならインターネット公開範囲を日本のみに限定する
- DMZ 構成を適正化する
- 同セグの通信防御を実装する
なお、5 番目以降は境界型防御の話です。
全体のまとめ
- IP レベルでの制御 (境界型防御) はいまだに最強のセキュリティ
- ゼロトラスト防御よりも優先すべきは「境界型防御」と「ソフトウェアの定期的・緊急バージョンアップの運用整備」、加えて「インターネット公開サーバの従来手法でのセキュリティ対策」
- 境界型防御ができないクラウド事業者はゼロトラストを実装するのが必然
- 境界型防御で防げないゼロデイ攻撃への対応としてゼロトラスト防御を適用するのは非常に良い手
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント