こんなセキュリティの間違いをしていませんか？認証システム開発で得た教訓

この記事は、 NTT Communications Advent Calendar 2023 1日目の記事です。

はじめに

こんにちは、イノベーションセンターの平木と申します。 11月1日にNA4Secプロジェクト¹のチームにセキュリティエンジニアとしてjoinしまして、急遽、エンジニアブログに投稿させていただくことになりました。今日ご紹介したいのは、前職（NTT Comの他部門）のセキュリティ機器の導入プロジェクトの話で、その中で私が遭遇した「嘘のような本当の話！？」をご紹介し、そこで得た学びをお伝えしたいと思います。

開発プロジェクトの概要

とある事件をきっかけに全社的にセキュリティ意識が今まで以上に高まって、より適切に権限をコントロールすべく、認可認証の仕組みが導入されることが決まりました。我々のチームでは、サーバネットワーク基盤を用意し、認証アプリを導入し、運用を確立することがミッションでした。そして私は、主にシステム構築のプロジェクトマネージャとして、スケジューリングから設計、ベンダコントロールなどを推進しました。

このプロジェクトの中で私が担当した業務の１つがセキュリティポリシーの設計です。そして、策定したポリシーの１つが「Firewallポリシーを許可リスト方式にする」ことでした。許可リスト方式とは、通過させる送信元/宛先通信の対象をリスト形式で指定し、それ以外の通信を遮断する方式です。例えば「送信元IPアドレスが192.0.2.1、宛先ポートがTCP22番ポート（SSH）となる通信」「宛先IPアドレスが198.51.100.2、宛先ポートがTCP443番ポート（HTTPS）となる通信」..といった形で対象となる通信をリスト形式で指定します。許可リスト方式を用いることで、通信を必要最小限の経路に限定し、意図しない侵入経路の発生を防ぎます。対照的に、遮断する通信を指定し、それ以外の通信を通過させる方式を拒否リスト方式と呼びます。

なぜ許可リスト形式としたか？部門内の他システムでは許可対象選定が甘く、不要な通信を含む/24や/20などの大きめのネットワークが許可され、結果的に内部ネットワークで重要なサーバへの通信が全許可されてしまっていたケースが過去に発生していました。そのため、必要な通信のみを許可して欲しいと考え、敢えて許可リスト形式という形を強調し開発を進めました。加えて、本システムは認証認可だけではなく、CLIやGUI操作のログを収集する機能も持っており、複数のネットワークが接続される環境でした。万が一不正侵入された場合には、複数ネットワークをまたがる中継点として悪用されかねない²ため、一般的なシステムよりも高いセキュリティレベルが求められます。そのために、EDR（Endpoint Detection and Response）や多要素認証に加えて、許可リスト方式でアクセス可能なホストをより厳格に制限することでセキュリティを強化することとしました。

そして事件は起こった！

まさかの全送信元IP許可

たまたま設計を見直す機会があって、許可リスト設定を確認したところ、なんとクライアントネットワークと一部のサーバネットワークについて、全送信元IPアドレスからの通信が許可されていることに気づきました。これでは、過去に重要なサーバへの通信が許可されてしまったことの反省が活かされていないことになってしまいます。なお今思い返すと、設定変更に気づける仕組みがあれば良かったと思いますが、構築開始当初で十分に仕組みやプロセスが整っておらず、当時は気づくことができませんでした。現在は運用プロセスで気づけるようになっています。

なぜ許可してしまったのか？

状況を確認したところ「クライアントネットワークと一部のサーバネットワークではIPアドレスを固定できないホストがおり、当該ネットワークの全IPアドレスから通信を許可せざるをえなかった」ということが分かりました。

結局どうしたか？

暫定対処としては、全許可によるリスクを改めて評価し、対象となるネットワークはインターネット公開システムを持っていない点等を考慮し、直接侵入されるリスクが低いことから、リスクを許容することになりました。本格対処としては、許可リストの目的・意図を明文化し、セキュリティポリシーを関係者で改めて共有しました。

ただし、そもそもの話として、許可リストが適切だったか？という点は再考すべきであったかもしれません。システムを導入しようとしたネットワークは、過去の経緯が積み重なった結果、構成が不明瞭となり、そもそもIPアドレスの精査が難しかったとも考えられます。当然この状況で精査をしようとしても、精査の負荷が大きくなるため、運用負荷を軽減すべくセキュリティポリシーを緩めざるを得なかったと捉えることができます。

今回の場合、境界型防御と一部、ゼロトラスト・アーキテクチャの思想を取り入れたハイブリット設計を採用しましたが、「ネットワークの場所だけで無条件に信頼しない」というゼロトラストの考え方をさらに推し進めて、IPアドレスに依存しないセキュリティコントロールを前提に設計した方が、もしかしたら既存システムやその運用プロセスにマッチする形で本来実現したかったセキュリティに近づけられたかもしれません。

学び

現行ネットワークに即したセキュリティ要件にすることの大事さ
許可リスト方式は設計する上では分かりやすいが、管理コストの高さなど負の側面もあるので導入に際しては慎重に検討を
理想的には、ゼロトラストの考え方を推し進めたIPアドレスに依存しないセキュリティコントロールの方が、運用しやすかった可能性がある

今回、たまたま初期構築のタイミングで、運用が整っていない中で、不適切な設定が入ってしまったという状況でした。なお、本件以降は、正式な運用が立ち上がり、第三者の目で許可リストを精査するプロセスが入ったため、同様の事象は起こっていません。そのため、許可リスト方式を採用するのであれば、このようにプロセスで防ぐ形が効果的だと考えています。