セキュリティの誤設定とは何か、再発時の検出方法

チームはベンチマークに基づいてシステムを強化し、未使用のポートを閉じ、ログ記録をオンにしてレビューを通過します。その後、パッチが設定をリセットし、エンジニアが深夜2時に障害を修正するためにファイアウォールルールを開けたまま閉じず、古いイメージから新しいサーバーが構築されます。数か月後、環境は承認されたものとはまったく異なって見えます。

これはセキュリティの誤設定です。OWASPはこれを2021年に5位、2025年に2位と評価しており、既知の脆弱性をすべて修正しても、誰も変更を忘れた設定で扉を開けたままにしてしまうため、順位は上がり続けています。

セキュリティの誤設定：誤っている、欠落している、またはデフォルトのままの設定

セキュリティの誤設定は、設定が欠落している、誤っている、または安全でないデフォルトのままになっていることによって引き起こされる弱点です。ソフトウェアは設計通りに動作しますが、その設定方法が脆弱性を生み出します。

脆弱性はコードの欠陥であり、ベンダーがパッチで修正します。誤った設定は、システムの展開や変更方法に関する決定、またはその欠如に起因します。修正は設定の変更であり、それを実施し維持するのはあなたのチームの仕事です。

誤設定はオペレーティングシステム、データベース、ウェブサーバー、クラウドプラットフォーム、ネットワーク機器、およびアプリケーションに存在することがあります。何も壊れずシステムが稼働し続けるため、しばしば見過ごされます。

サーバー、クラウド、およびネットワーク機器におけるセキュリティの誤設定例

これらの多くは設定ファイルの1行に集約されます。ここでは、2つの一般的な設定ファイルでのドリフトの様子を示します。

      # /etc/ssh/sshd_config 

 

# Drifted 

PermitRootLogin yes 

PasswordAuthentication yes 

 

# Hardened 

PermitRootLogin no 

PasswordAuthentication no 
      

      # nginx.conf 

 

# Drifted 

autoindex on;        # directory listings exposed 

server_tokens on;    # version number in every response 

 

# Hardened 

autoindex off; 

server_tokens off; 
      

両方のずれたバージョンは正常に動作するため、誰も気づきません。 Change Trackerはこのような設定ファイルを監視し、値が変更された瞬間を検知できます。

これらのほとんどは設定変更だけで修正できます。大規模な環境でそれらを見つけるのが遅い部分です。

強化後も設定ミスが繰り返し発生します

セットアップのミスは起こり得ますし、セットアップ後の変更も同様です。後者の技術用語は「configuration drift（構成ドリフト）」で、承認され強化された状態からシステムが徐々に逸脱していくことを指します。

パッチやアップデートは副次的に設定を変更します。ビジネスが待てないため、緊急修正は通常のプロセス外で行われます。同一であるはずのシステムが異なる時期に異なる人によって構築されます。何かが変更されると、誰がいつなぜ変更したのかの明確な記録がないことが多いです。

だからこそ、一度きりの監査では不十分です。監査した日のシステム状態を示すだけで、翌日から変動が始まる可能性があります。四半期ごとや年次でレビューするチームは、常にすでに古くなったスナップショットをもとに作業しています。

誤設定されたシステムがもたらすコスト

誤設定されたシステムは攻撃者に侵入しやすい経路を与え、監査人には指摘事項をもたらします。どちらも時間と費用がかかります。

設定ミスはデータを露出させ、攻撃者が内部に入った後のアクセス範囲を広げ、ログがそれを検知するように設定されていないため侵入を見つけにくくします。誤った設定は障害を引き起こすこともあり、原因を突き止めるのに何時間もかかり、誰も何が変わったのか言えません。フレームワークとしては PCI DSS、NIST 800-53、HIPAA は、組織が安全な構成基準を維持し、システムがそれに適合している証拠を示すことを求めています。ずれたシステムは、まだ問題が起きていなくてもそのテストに失敗します。

セキュリティの誤設定を4つのステップで見つけて修正する

1. 標準から始めましょう。 比較対象がなければ誤設定は見つかりません。ほとんどの組織は CIS Benchmarks やDISA STIGなどの業界ベンチマークから始めて、自分たちの環境に合わせて調整します。中には、すでに強化し信頼しているシステムから独自の標準を作るところもあります。
2. すべてのシステムをそれに照らして評価します。 サーバー、データベース、クラウドアカウント、ネットワーク機器をベンチマークと照らし合わせて結果を評価します。重要度に応じてランク付けされた問題のリストが得られます。
3. 見つけた問題を修正する。最もリスクの高いものから始めてください。意図的な逸脱の場合は、誤警報とならないように承認された例外として記録してください。
4. 変更を監視します。 修正後も環境は変化し続けます。継続的な監視により、システムが承認された状態から逸脱した時を知ることができ、次の監査で見つけるのではなく数時間で逸脱した設定を修正できます。

コンテキストのない検出はアラートノイズになります

チームが監視を追加すると、アラートが次々と届き始めます。すべてのパッチ、メンテナンスウィンドウ、承認された更新は変更イベントを生成する可能性があり、数百台のデバイスの中でチームは通常の変更とリスクのある変更を区別できません。

設定ファイルの変更は、意図されていなかった場合にのみ問題となります。違いを判断するには、変更された内容と承認された内容を比較する必要があります。

クローズドループの変更管理はその比較を行います。承認された変更は、ITサービス管理システムに既に存在するリクエストに接続するか、直接定義することで計画された変更として記録されます。システムに変更が現れると、計画と照合されます。一致すれば計画されたものとして分類され、問題になりません。それ以外は計画外としてフラグが立てられ、その短いリストがチームによって調査されます。

Netwrix Change Trackerをご紹介

Netwrix Change Trackerはシステムを既知の基準と比較し、変化をリアルタイムで検出し、計画された変更と計画外の変更を区別します。

評価のために、Change Tracker は CIS Benchmarks に基づくコンプライアンスレポートを含み、Netwrix は CIS 認定ベンダーです。レポートは Windows、Linux、Unix、データベース、ネットワーク機器、VMware ESXi、および Azure、AWS、GCP、Microsoft 365 を含むクラウドプラットフォームをカバーします。組織に独自のビルド標準がある場合、任意のデバイスをベースラインソースとして使用できるため、信頼できるシステムからゴールドビルドを定義し、それに対して他を測定できます。

監視のために、ファイル、フォルダ、ファイル内容に加え、プロセス、サービス、開いているネットワークポートを追跡します。Windowsでは、レジストリ設定、インストール済みソフトウェア、ローカルアカウント、セキュリティおよび監査ポリシーも追跡します。収集はエージェントの有無にかかわらず動作し、ソフトウェアをインストールできないサーバー、アプライアンス、デバイスが混在する環境で重要です。すべての変更は何がいつ変更されたか記録され、問題発生時に検索可能な履歴を構築できます。

変更管理では、検出された変更を計画された変更と比較します。ServiceNow、BMC Remedy、Cherwell、ManageEngine ServiceDesk Plus、OpenText Service ManagementなどのITSMプラットフォームと統合されており、承認されたリクエストは自動的に計画された変更になります。計画外の変更はServiceNowでインシデントを発生させ、システム所有者に調査を促します。

いつでも確認できるセキュリティ構成を提供し、変更点を尋ねられたときに明確な回答を得られます。