サーバー・ハードニング・ポリシー：例とヒント

さまざまな調査により、報告された侵害の驚くべき80%が、ITシステムの設定に存在する脆弱性を悪用することに関係していることが明らかになっています。攻撃を事前に阻止し、費用のかかるダウンタイムや データ侵害 を防ぐために、専門家はサーバー ハードニング・ポリシー の導入を推奨しています。これは システム・ハードニング の一種です。

サーバー・ハードニング・ポリシーとは、システムを不正アクセスや悪用から保護するために設計された一連のガイドライン、手順、およびコントロールのセットです。実際、デフォルト状態のまま導入されたサーバーは、侵害やマルウェア攻撃のリスクがあります。しかし、不必要なソフトウェアや機能を削除し、セキュリティ設定を適切に構成し、アクセス制御、監査、インシデント対応に関するベストプラクティスを実装することで、攻撃対象領域（攻撃面）を大幅に減らすことができます。

以下のヒントと例は、ハードニング作業の出発点としてご利用いただけます。

ユーザー アカウントとパスワード

• アカウントのロックアウトの期間としきい値は設定されていますか？
• Kerberos の暗号化は有効化されており、選択した暗号化タイプは十分に強力ですか？
• Windows システムの組み込み Administrator や Guest アカウントなどのデフォルトのローカル アカウントは無効化または名前の変更がされていますか？
• ユーザーのパスワード要件が、NIST ガイドラインなどのベスト プラクティスに沿っていますか？

例： 次のパラメータでアカウント パスワード ポリシーを設定します。

• 最小パスワード有効期間：1 日以上
• 最小パスワード長：14 文字以上
• アカウントのロックアウト閾値：10回以下の試行（ただし0は除く）
• アカウントのロックアウトカウンターをリセット：15分以上

オペレーティングシステム

• すべてのオペレーティングシステム（OS）はベンダーによって完全にサポートされており、最新レベルまでパッチが適用されていますか？また、これを少なくとも月1回は見直していますか？
• 不要なすべてのサービスおよびデーモンは削除または無効化されていますか？Web、FTP、telnet、リモートデスクトップへのアクセスは削除されていますか？最善のヒントは、不要だと分かっているものはすべて無効化すること（例：Themes サービス）です。そのうえで、不要だと思われる他のサービスについては1つずつ慎重に実験してください。サービスを無効化すると業務運用に支障が出る場合は、有効のままにしておきます。
• どのポートが開いているか分かりますか？それらを開いたままにしておくのに十分な理由があるのか、それとも削除できるのか？新しい開放ポートが現れたときに検出できますか？
• ローカルの Security Policy は十分に活用されていますか？悪用可能な脆弱性は、このポリシーを使うことで軽減できます。このポリシーは、セキュリティを強化するためのきめ細かなセキュリティ設定制御を数百項目提供します。

例：Windows オペレーティング システムに対して次の設定を定義します：

• UIAccess アプリケーションに対して、安全なデスクトップを使用せずに昇格のプロンプトを表示することを許可する: 無効
• 管理者承認モードでの管理者の昇格プロンプト: 安全なデスクトップで同意を求める
• 標準ユーザーの昇格プロンプト：昇格要求を自動的に拒否する
• アプリケーションのインストールを検出して昇格を促す：有効
• 安全な場所にインストールされている UIAccess アプリのみを昇格させる：有効
• すべての管理者を Admin Approval Mode で実行する：有効
• ファイルおよびレジストリの書き込み失敗をユーザーごとの場所に仮想化する：有効

ファイルシステム

• Unix および Linux サーバーでは、主要なセキュリティファイル（/etc/password や /etc/shadow など）の権限は、ベストプラクティスの推奨に従って設定されていますか？ sudo は使用されていますか？使用されている場合、root wheel のメンバーのみが利用できるようになっていますか？
• Windows サーバーでは、主要な実行ファイル、DLL、およびドライバーが System32 および SysWOW64 フォルダー内で保護されているだけでなく、Program Files/(x86) も保護されていますか？

例: 次のファイルおよびフォルダーに適用 ファイル整合性監視：

• %PROGRAMFILES%：SHA1 ハッシュを使用、システムファイルの変更を監視、ログファイルを除外、再帰
• %PROGRAMFILES(x86)%：SHA256 ハッシュを使用、システムファイルの変更、ログファイルを除外、再帰
• %SYSDIR%：SHA256 ハッシュを使用、システムファイルの変更、ログファイルを除外、再帰
• %WINDIR%SysWOW64：SHA256 ハッシュを使用、システムファイルの変更、ログファイルを除外、再帰

クライアント/サーバー ネットワーク

• 組み込みのソフトウェアファイアウォールが有効化され、 「Deny All（すべて拒否）」として設定されていますか？
• Linux では、TCP Wrappers が「Deny All」に設定されていますか？
• リモートでアクセス可能なレジストリ パスと共有は、環境に合わせて適切に制限されていますか？メンバー サーバーとドメイン コントローラーでは対応が異なります。

例: セキュリティ ポリシーで、次のネットワーク クライアントおよびネットワーク サーバーの設定を指定します:

• 通信にデジタル署名（サーバーが同意する場合）：有効
• 第三者の SMB サーバーに未暗号化のパスワードを送信：無効
• 通信をデジタル署名します（常に）：有効
• 通信をデジタル署名します（クライアントが同意する場合）：有効
• ログオン時間が期限切れになったらクライアントを切断：有効

監査と変更管理

• すべてのアクセス、特権の使用、構成変更、ならびにオブジェクトへのアクセス、作成、削除について監査ログ（監査トレイル）が有効になっていますか？
• 監査ログ（監査トレイル）は安全にバックアップされ、少なくとも 12 か月間保持されていますか？
• 中央で保護された NTP ソースが構成され、使用されていますか？
• file integrity monitoring（FIM）を使って、セキュアなビルド基準を維持していますか？
• 定義された change management プロセスがあり、変更提案（影響分析およびロールバックの規定を含む）、変更承認、QA テスト、ならびに導入後のレビューが含まれていますか？
• 記録されたイベントは、中央サーバーに安全にバックアップされていますか？そのためには、監視対象サーバーからログサーバーへイベントを転送する手段が必要です（通常は Syslog の転送エージェント、または Netwrix Change Tracker のような、より包括的なソリューションです）。さらに、構造化された audit policy も必要です。

例：高度な監査ポリシーで、次の設定を定義します:

• ログオフの監査：成功
• ログオンの監査：成功と失敗
• その他のログオン/ログオフ イベントの監査：成功と失敗
• 特殊ログオンの監査：成功

ソフトウェアとアプリケーション

• セキュアなビルド基準で定義しているパッケージやアプリケーションはどれですか。たとえば、アンチウイルス、データ漏えいの防止、ファイアウォール、FIM ツールに関する標準はありますか？承認済みの変更がある場合に、ベースラインを定期的に更新する手順は何ですか？
• 最新バージョンを保有し、パッチがテストされ適用されていることを確認するためのプロセスはありますか？
• ソフトウェアパッケージへの自動更新は無効にして、予定された更新の配布を優先していますか？

サーバーのハードニングポリシーを選択し、自組織に合わせて調整する

ハードニングのチェックリストやサーバーのハードニングポリシーを用意することは、十分に簡単です。たとえば Center for Internet Security (CIS) は ハードニングのチェックリスト を提供しています。Microsoft は Windows デバイス向けのチェックリストを提供し、Cisco は自社のルーター向けのチェックリストを提供し、また NIST がホストする National Vulnerability Database は、Linux、Unix、Windows、ファイアウォールなど幅広いデバイス向けのチェックリストを提供しています。NIST はさらに、SCAP および OVAL の標準に基づく National Checklist Program Repository も提供しています。

これは良い出発点ですが、あらゆるチェックリストはサーバーの運用と役割に基づいて調整する必要があります。たとえば、インターネットに公開されたサーバーは、ファイアウォールの内側にあるデータベースサーバーよりも強力なアクセス制御を必要とします。

サーバーのハードニングポリシーを確立し、ベストプラクティスのチェックリストを標準ビルドに適用したら、設定のドリフト（configuration drift）がないか、すべてのデバイスを継続的に監査する必要があります。変更管理プロセスでは、変更がどのように評価され、その後「是正（remediated）」されるのか、または「構成ベースライン（configuration baseline）」に昇格されるのかを定義する必要があります。 Netwrix Change Tracker はインテリジェントな変更制御を提供するため、ある1台のサーバーに対して変更を承認するのは1回だけで済み、その後同じ変更が他の箇所で発生した場合は自動的に承認されます。これは、ほとんどの FIM および SIEM システムに共通する最大の問題、つまり変更ノイズ（change noise）が簡単に過剰になってしまう点を解消します。

概要

あらゆる data security 戦略で最も効果的な第一歩は、セキュリティ侵害を防ぐことです。ハードニング（hardening）によって設定上の脆弱性に事前に対処することで、サーバーをより安全にし、攻撃への耐性を高められます。変更管理と file integrity monitoring のソリューションは、その後、ベースライン（baseline）からのあらゆる逸脱を監視することで、すべてのサーバーが安全に構成された状態を維持できるようにします。

FAQ

サーバー ハードニングとは？

サーバー ハードニングとは、不要なプログラムや機能を無効化し、サーバーのセキュリティ設定を強化し、監査とインシデント対応のベストプラクティスを徹底することで、サーバーを攻撃に対してより脆弱にしないようにするための積極的なプロセスです。

ハードニング ポリシーとは？

ハードニングポリシー（hardening policy）とは、システムの攻撃対象領域（attack surface area）を減らすために実施する一連のガイドラインと手順のことです。ポリシーは、アクセス制御、ログ記録、インシデント対応（incident response）に関する内容に基づくべきです。ポリシーは、Linux や Windows Server のように特定のシステムに固有のものにすることも、データベースのハードニングポリシーのように一般化したものにすることもできます。

システムのハードニングポリシーテンプレートとは？

システムのハードニング ポリシーテンプレートとは、システムを確保し、保護するために従うべきガイドラインと手順を示した文書です。通常、特定のアセット（資産）に対して実装するべきベストプラクティス（best practices）やセキュリティコントロール（security controls）のリストが含まれます。このテンプレートは、さまざまなシステム向けにカスタムのハードニングポリシーを作成するための出発点として利用できます。

サーバーのセキュリティをどのようにハードニングすればよいですか？

主なステップには通常、次が含まれます：

• 不要なソフトウェアやサービスを削除して、攻撃対象領域を減らします
• ファイアウォールおよび侵入検知/防止システムを設定して、不正アクセスをブロックします
• 暗号化やセキュアブートなどのセキュリティ機能を有効にします
• 多要素認証や最小権限などのアクセス制御のベストプラクティスを実装します
• ソフトウェアを定期的に更新し、セキュリティパッチを適用します
• 想定されるセキュリティインシデントを検知し対応するために、強力なイベントロギングとトラフィック監視を実装する
• 脆弱性を特定して対処するために、サーバーのハードニングポリシーを定期的にテストし、見直します。