サーバーを保護するための堅牢なセキュリティ対策を構築する方法

はじめに

クラウドインフラストラクチャを構築する際、最も重要な関心事はアプリケーションが完全に動作していることを確認することです。セットアップおよびデプロイプロセスの重要な要素の1つは、アプリやシステムを一般に公開する前に、効果的で徹底した堅牢なセキュリティ対策を組み込むことです。デプロイ後に遡ってセキュリティ対策を実装するのではなく、インフラストラクチャに安全な基本設定が組み込まれていることを確認することが重要です。

このチュートリアルは、その点において役立ちます。サーバーのインフラストラクチャがセットアップおよび設定される際に実装できる、いくつかの実用的なセキュリティ対策に焦点を当てます。これはサーバーセキュリティプロトコルの網羅的なリストではありませんが、役立つ出発点となります。環境やアプリケーションの具体的なニーズを理解し、それに対応していく中で、ベースとなるセキュリティをさらに強化するための追加のセキュリティ対策を開発することができます。

SSH（Secure Shell）キー

サーバーを操作する際、その時間の大部分は、ターミナルセッションでサーバーとのSSH接続を介して行われます。SSH（セキュアシェル）キーは、パスワードに依存するログインよりも安全なサーバーへのログオン方法を提供します。認証を目的として、SSHキーを使用する場合、2つのアクセスキーが用意されます。1つは秘密（プライベート）キーで、もう1つは共有可能な公開キーです。

SSHキー認証は、まず設定を行う必要があります。これは、SSH公開キーをサーバー上の適切なディレクトリに配置することで実現されます。クライアントが最初にサーバーに接続すると、秘密キーを所有していることの証明が求められます。これは、ランダムな値を生成してSSHクライアントに送信することによって行われます。次に、SSHクライアントは秘密キーを使用して応答を暗号化します。この応答がサーバーに送信されます。その後、サーバーは公開キーを使用してクライアントからのメッセージを復号します。ランダムな値がサーバーによって正常に復号された場合、クライアントが秘密キーを所有していることを示します。その場合、認証が確認され、パスワードなしでサーバーへの接続を確立できます。

SSHキーによるセキュリティの強化

パスワード認証やSSHによる認証は完全に暗号化されていますが、悪意のあるユーザーによってサーバーへのアクセスが試みられる可能性があります。特に、サーバーの外部向けIPアドレスが知られてしまっている場合はなおさらです。現代のコンピューティング能力では、考えられるすべてのキーの組み合わせを試すことで、パスワードベースのログインを突破することが可能であり、悪意のあるユーザーによって頻繁に試みられています。これらのアクセス試行を自動化すれば、さまざまな組み合わせを体系的に試すことで、最終的に正しいパスワードにアクセスすることが可能になります。

SSH暗号化認証を活用することで、ログイン用のパスワードを有効にする必要がなくなります。SSHキーには通常、攻撃者が試行しなければならない膨大な数の組み合わせが存在します。ビット数が増えることで、暗号化を解読するために必要な異なる組み合わせの可能性が乗算的に増加します。したがって、SSHキーアルゴリズムの考えられるすべての組み合わせを網羅することは、計り知れない時間を要します。そのため、悪意のある攻撃者にとって時間を費やす価値のない試みとなります。これが、SSH暗号化が通常「解読不可能」と見なされる理由です。

SSHキーの実装

リモートのLinuxサーバーにログオンする際は、SSHキーを使用する必要があります。ローカルマシン側でキーを生成し、公開キーを数分以内にサーバーに転送することができます。このチュートリアルでは、UbuntuでSSHを使用してリモートサーバーに接続する方法についての基本的な概念を理解できます。また、詳細なLinuxサーバーでSSHキーベースの認証を使用するように設定する方法のチュートリアル.

全体として、rootユーザーがSSH経由で直接ログインすることを許可しないのは一般的に用いられるベストプラクティスであり、代わりに非特権ユーザーとしてログインし、必要に応じてsudoのようなツールを使用して権限を昇格させます。これは「最小特権の原則」として知られており、アクセス権限を制限する方法です。非特権アカウントでのログインがSSHで確認できたら、サーバー上の /etc/ssh/sshd_config で PermitRootLogin no ディレクティブを設定することで、rootログインを無効にできます。その後、SSHプロセスのコマンド sudo systemctl restart sshd を使用してサーバーを再起動できます。

ファイアウォール

ネットワークに対するサービスの公開を規制するソフトウェア（またはハードウェアデバイス）は、ファイアウォールと呼ばれます。最適に設定されたファイアウォールは、許可されたサービスのみが公開され、特定のサーバーへの出入りが許可されるようにします。

サーバー上ではデフォルトでいくつかのサービスが実行されている場合があり、これらは以下のグループに分類できます。

• 内部サービス： これらはサーバー自体から内部的にのみアクセスされる必要があります。これにより、公開されているインターネットからのアクセスにサービスがさらされるのを防ぎます（例：ローカル接続経由でのみ到達可能なデータベース）。
• 公開サービス： インターネット上の誰でも、多くの場合匿名でアクセスできるサービスです。これには、訪問者がサイトにアクセスできるようにするWebサーバーなどが含まれます。
• プライベートサービス： 特定の場所の許可されたアカウントのみがこれらのサービスにアクセスできます（例：phpMyAdminデータベースコントロールパネル）。

公開サービスはインターネットからアクセス可能な状態にしておくことができますが、プライベートサービスはアクセスパラメータ（接続タイプなど）に基づいて制限でき、内部サービスはインターネットベースのアクセスを完全に遮断します。これらのサービスへのアクセスと、それが許可される粒度はすべてファイアウォールによって制御されます。未使用のポートは、通常、アクセスを完全にブロックするように設定されます。

ファイアウォール使用によるセキュリティ強化

ファイアウォールはサーバー保護の基準です。アプリケーションがトラフィックを処理する前に、サービスへの接続およびサービスからの接続を制限する役割を果たします。もちろん、サービスに追加のセキュリティ機能を実装し、それらを目的のインターフェースに制限することもできます。

適切に設定されたファイアウォールによって制限されないのは、開いたままにすることを選択したサービスのみです。これにより、利用可能なソフトウェアが大幅に制限されるため、悪用の脆弱性がある要素が制限され、攻撃を受ける可能性が低くなります。

ファイアウォールの実装

Linuxシステムでは多くのファイアウォールが利用可能です。中には非常に複雑なものもあります。ただし、一般的なファイアウォールの設定は、サーバーの初期設定時や、サーバーからのサービスに変更が加えられたときにのみ行う必要があります。これには数分しかかかりません。ファイアウォールを設定して有効にするために検討すべきいくつかのオプションを以下に示します。

• CentOSについては、当社の CentOS 7でFirewallDを使用してファイアウォールを設定するガイド.
• 当社の Iptablesガイドでは、Iptablesファイアウォールルールの表示と削除の手順を説明しています.

最も重要なことは、どのチュートリアルを使用するかに関わらず、新しく利用可能になったサービスが意図せずインターネットに公開されるのを防ぐために、選択したファイアウォールがサーバーからの不明なトラフィックをブロックするようにすることです。アクセスを明示的に許可する必要があるため、サービスがどのようにアクセスされ、実行され、誰にアクセスが許可されているかを十分に評価するよう促されます。

仮想プライベートクラウド（VPC）ネットワーク

インフラストラクチャ’のリソースは、VPCと呼ばれるプライベートネットワーク内で動作する必要があります。これらのネットワークは、他のクラウドベースのVPCネットワークからのアクセスを防ぐため、より安全です。したがって、ネットワークのインターフェースはパブリックインターネットからアクセスできなくなります。

VPCネットワークによるセキュリティの強化

内部通信においては、パブリックなネットワークよりもプライベートネットワークの方が好ましいです。VPCを使用すると、リソースグループを特定のプライベートネットワークに分離できます。VPCネットワークはプライベート接続を介してのみインターフェースするため、ネットワークのトラフィックはパブリックインターネットへの露出から保護され、情報が傍受されたり漏洩したりする脆弱性から守られます。また、VPCネットワークは、テナントだけでなく実行環境を分離するためにも使用できます。インターネットゲートウェイは、パブリックインターネットとVPCネットワーク上のリソースとの間の単一のアクセスポイントとして設定することもできます。

さらに、セキュリティの大部分は、システムを分析し、すべてのコンポーネントを最大限に保護することにあります。サービス監査により、システムが許容するプロトコル、実行中のサービス、および通信に使用されているポートを把握できます。この情報を知ることで、設定に関する最適な意思決定を行うことができます。このような決定には、ファイアウォールの設定、システムの監視とアラート、およびどのサービスをパブリックにアクセス可能にするかなどが含まれます。

監査を活用したセキュリティの強化

各サービスは、外部クライアントの処理または内部目的のために利用できます。意図に関係なく、これらのサービスはすべて悪意のあるユーザーに対する脆弱性のポイントとなります。実行されるサービスの数が増えると、脆弱性が悪用される可能性も高まります。

マシンでどのようなサービスが実行されているかをしっかりと把握できたら、サービスの分析を開始できます。サービス監査を実行する際は、以下の質問を行うことが有益です。

• その特定のサービスはアクティブに実行されている必要がありますか？
• 最適なネットワークインターフェース上で実行されていますか？
• そのサービスは、パブリックまたはプライベートのどちらのネットワークインターフェースに最も適していますか？
• ファイアウォールルールは、このサービスへの正当なトラフィックを許可するように正しく設定されていますか？
• ファイアウォールルールによって不正なトラフィックはブロックされていますか？
• セキュリティの脆弱性に関するアラートシステムは有効になっていますか？

インフラストラクチャに新しいサーバーを追加する場合、上記は設定プロセスにおける標準的な慣行であるべきです。サービス監査の追加のメリットは、意図せず変更された設定を特定できることです。

サービス監査の実行

実行中のサービスを監査するには、ssコマンドを使用して、サーバー上でアクティブに使用されているすべてのUDPおよびTCPポートを一覧表示します。以下は、プログラム名PIDを指定してssコマンドを使用し、リスニング状態のTCPおよびUDPポートを確認する例です。

以下のような結果が返されます。

主に注目すべきなのは、Netid、Local Address:Port、およびProcessの列です。

• Local Address:Portの値が0.0.0.0の場合、そのサービスがすべてのIPv4 networkインターフェースにわたるすべての接続をアクティブに受け入れていることを意味します。アドレスが[::]の場合、すべてのIPv6接続がトラフィックを受け入れています。
• 上記の例では、NginxとSSHの両方が、両方のネットワークスタック（IPv4およびIPv6）のすべてのパブリックインターフェースでリスニングしています。

上記の例では、SSHとNginxが2つのインターフェースでリスニングすることを許可する必要があるか、あるいはどちらか一方のみにするかを選択できます。一般的には、未使用のサービスは実行されないように無効化することが望ましいです。たとえば、サイトへのアクセスをIPv4のみに制限したい場合は、IPv6インターフェースをオフにして露出を制限することが役立ちます。

自動アップデートによる最新状態の維持

自動アップデート（Unattended updates）は、サーバーのセキュリティを維持するために必要な労力を軽減し、既知のバグにさらされる時間を短縮するのに役立ちます。サーバーのアップデートを実行するまでに時間がかかるほど、既知の脆弱性にさらされる時間が長くなります。自動アップデートを使用すると、修正パッケージが利用可能になり次第、サーバーに自動的にインストールされるため、脆弱性が存在する時間を最小限に抑えることができます。

サーバー監査に加えて、自動アップデートは攻撃にさらされるリスクを大幅に軽減できます。また、サーバーのメンテナンスに費やす時間も大幅に削減されます。

無人アップデートの有効化方法

現在、ほとんどのサーバーディストリビューションにおいて、無人アップデートはオプション機能となっています。例えばUbuntuでは、管理者は次のコマンドを実行できます：

無人アップデートの導入に関する詳細については、こちらの「自動アップデート」セクションを参照してください。Fedoraの場合、手順はこちらにあります。自動アップデートは、システムのパッケージ管理システムを通じて最初にインストールされたソフトウェアのみをインストールすることにご注意ください。ウェブベースのアプリケーションなどの追加のアプリケーションは、手動で個別にアップデートを確認するか、自動アップデート用に個別に設定する必要があります。

ディレクトリインデックス

ディレクトリにインデックスファイルがない場合、ほとんどのサーバーはデフォルトでディレクトリインデックスを表示するように設定されています。言い換えれば、ウェブサーバー上に「downloads」というディレクトリが作成された場合、そのディレクトリを閲覧する誰もがそこにあるすべてのファイルを見ることができます。これは必ずしもセキュリティリスクとは限りませんが、関係のない人の目に機密情報が触れることになります。例えば、ウェブサーバーにウェブサイトのホームページへのアクセス資格情報を含むファイルや、サイトのデータベースのバックエンドへのすべての設定を含むファイルがある場合を考えてみてください。ディレクトリインデックスが無効になっていない場合、これらのファイルはそのディレクトリを閲覧するすべての人に見られてしまいます。

ディレクトリインデックスの無効化によるセキュリティの向上

ディレクトリインデックスは便利ですが、意図せずファイルが公開されてしまう可能性があります。このような意図しない公開やそれに伴うリスクを軽減するために、サーバー上のディレクトリインデックスはデフォルトで無効にする必要があります。訪問者は引き続きファイルにアクセスできますが、意図しないデータ閲覧にさらされるリスクは大幅に制限されます。

ディレクトリインデックスの無効化

ほとんどの場合、ウェブサーバーの設定に1行追加するだけで、ディレクトリインデックスを無効にすることができます。

• 以下のApache Wikiのディレクトリ一覧を無効にする手順に従ってください。ApacheのDirectory設定ブロックに「Options -Indexes」が記載されていることを確認してください。
• Nginxではインデックスはデフォルトで無効になっているため、この点に関してこれ以上の対応は必要ありません。

定期的なバックアップ

バックアップはセキュリティ対策そのものではありませんが、システムが侵害された場合にデータやシステム全体を保護するために不可欠です。また、システムがどのように攻撃を受けたかを分析するのにも役立ちます。システムがランサムウェア（システム上のファイルを暗号化し、ハッカーにお金を支払った場合にのみ復号するウイルスやマルウェアツール）による攻撃を受けるという不幸なシナリオを考えてみてください。データのバックアップがない場合、データへのアクセスを取り戻すためにお金を支払うしか選択肢はありません。データが安全にバックアップされていれば、データへのアクセスを維持し、侵害されたシステムにアクセスすることなくデータを復旧することができます。

定期的なバックアップによるセキュリティの強化

定期的なバックアップは、攻撃、破損、あるいは意図しない紛失（削除）が発生した場合に情報を回収するのに役立ちます。どのような否定的な出来事によってデータが失われたとしても、サーバーデータのコピーを保持しておくことでそのリスクは軽減されます。

ランサムウェア攻撃以外にも、定期的なバックアップは長期にわたるシステム攻撃の具体的な調査に役立ちます。データをバックアップ形式で安全に外部に保存していない場合、攻撃の発生源やどのデータが侵害されたかを特定することは困難、あるいは不可能になる可能性があります。

定期的なバックアップの実施

システムをバックアップする際、破損、侵害、または削除されたデータの検証可能な復旧を復旧作業の目標とすることが極めて重要です。最も分かりやすく言えば、明日サーバーが消滅した場合に、最小限の作業で復旧して稼働させるにはどのようなアクションが必要かを考えてみてください。

災害復旧計画を検討する際に考慮すべきその他のポイントは以下の通りです：

• 動的に変化するデータを扱っている場合、バックアップの頻度を高くする必要があるでしょう。データ損失が発生した際、最後のバックアップが古すぎると、古いデータに戻らざるを得なくなる可能性があります。
• 実際のバックアップ復元プロセスについて考えてみましょう。復元のために新しいサーバーを追加する必要があるでしょうか、それとも既存のサーバーを復元できるでしょうか？
• サーバーが稼働していない状態を許容できる最長期間はどれくらいですか？
• オフサイトバックアップは必要なソリューションですか？

CloudSigmaの災害復旧（Disaster Recovery）ソリューションの詳細については、以下の詳細を説明したブログ記事をご覧ください。当社のDisaster-Recovery-as-a-Serviceがクラウドの完璧なパートナーである理由。また、こちらでは以下について詳しくご覧いただけます。CloudSigmaのセキュリティ&ビジネス継続性機能。また、以下の詳細なガイドもご用意しています。CloudSigmaのバックアップ機能を簡単に設定する方法.

プライベートネットワークとVPN

プライベートネットワークとは、特定のユーザーまたはサーバーのみがアクセスおよび使用できるネットワークのことです。リモートデバイス間で安全な接続を確立し、プライベートネットワーク内にあるかのように動作できるようにする接続が、VPN（仮想プライベートネットワーク）です。これにより、プライベートネットワーク内の接続を保護し、リモートサーバーを接続することができます。

プライベートネットワークはどのようにセキュリティを向上させるのか？

内部通信にパブリックネットワークとプライベートネットワークのどちらを使用するか選択できる場合、常に後者（プライベート）が望ましい選択肢です。ただし、データセンター内の他のユーザーも同じネットワークにアクセスできる可能性があることに注意してください。つまり、サーバー間の通信の安全性を確保するために、追加のセキュリティ対策を適用する必要があります。

本質的に、VPNの利用は、組織の従業員が閲覧できる範囲を定義するためのアプローチです。通信は完全に安全かつプライベートになります。アプリケーションの設定により、仮想インターフェースのトラフィックをVPN経由で通過させることができます。そうすることで、インターネットを介したクライアントとのやり取りを目的としたサービスのみがパブリックネットワークに公開されるようになります。

VPNの導入はどのくらい難しいか？

データセンターでプライベートネットワークを活用することは、アプリケーションやファイアウォールがプライベートネットワークを使用するように設定し、サーバー作成時にVPNを有効にするのと同じくらい簡単です。ただし、他のサーバーもデータセンター全体のプライベートネットワークと同じネットワークスペースを共有していることを忘れないでください。

VPNの初期設定は少し複雑です。しかし、それによって得られるセキュリティの向上は、ほとんどのユースケースにおいて価値があります。設定データと共有セキュリティをネットワーク上の各サーバーにインストールして設定する必要があります。詳細については、以下のVPNの仕組みとUbuntuでのOpenVPNの設定概要に関するガイドをご覧ください。また、以下の手順を説明したチュートリアルもご覧いただけます。VPNネットワークをCloudSigmaのインフラストラクチャに接続する手順.

SSL/TLS暗号化と公開鍵暗号基盤（PKI）

個人を識別するための証明書の生成、管理、検証、および通信の暗号化は、公開鍵暗号基盤（PKI）と呼ばれます。異なるエンティティ間では、SSLまたはTLS証明書を使用することで、相互に認証を行うことができます。その後、暗号化された通信を確立するためにも使用できます。

証明書はどのようにセキュリティを向上させるのか

サーバー上のトラフィックを暗号化し、メンバーの身元を検証するには、認証局（CA）を構築し、ネットワークのすべての証明書を確認できるようにすることが不可欠です。これにより、ハッカーがサーバーになりすましてトラフィックを別の場所にリダイレクトする「中間者攻撃」を防ぐことができます。

各サーバーの設定は、中央のCAを信頼するようにセットアップできます。これにより、それ以降の証明書の署名は暗黙的に信頼されます。サーバーが使用するプロトコルやアプリがSSL/TLS暗号化をサポートしている場合、VPNトンネルのオーバーヘッドなしでシステムを保護できます。詳細については、当社のNginx用のLetsEncrypt SSL証明書の自動更新方法に関するチュートリアルをご覧ください.

導入の難易度

認証局（CA）を構成し、残りのPKIを設定するには、最初に多くの労力がかかる場合があります。また、新しい証明書の作成、失効、または署名が必要な場合、追加の管理労力が必要になります。

ほとんどのインフラストラクチャは拡張する必要があるため、本格的なPKOを導入することが最も賢明なアプローチです。PKIが追加の管理コストに見合う段階に達するまでは、VPNを利用してシステムのコンポーネントを保護することが、適切な一時しのぎの対策となります。

システム侵入の検知とファイル監査の活用

ファイル監査とは、完全に安全で良好な状態にあるシステムのファイルとその属性を、現在のシステムのファイルと比較するために使用されるプロセスです。これは、不正なシステムの変更を発見し、隔離するための優れた方法です。

An IDS（侵入検知システム）とは、システム上の不正なアクティビティを監視するモニタリングソフトウェアを指します。一般的に、予期しないシステムの変更を探し出すためにファイル監査手法を使用します。

IDS/ファイル監査によるセキュリティの強化

単なるサービスレベルの監査にとどまらず、ファイルレベルの監査を実行することは、システムのセキュリティを確保するために不可欠です。これは、自動化されたIDSプロセスによって行うことも、システム管理者によって定期的に実行することもできます。

ファイル監査とIDSは、システムに予期しない変更が加えられていないことを確認するための唯一の確実なプロセスです。ほとんどの侵入者は、侵入したサーバーを長期間にわたって悪用したいと考えており、そのためには自らの行動を隠蔽し続ける必要があります。彼らはバイナリを脆弱なバージョンや改ざんされたバージョンに置き換える可能性があります。システム内で変更されたファイルは、ファイルシステム監査によって検出されます。これにより、システムの整合性が損なわれているかどうかを非常に迅速に把握できるため、安心感が得られます。

導入の難易度

IDSとファイル監査の導入は、非常に骨の折れるプロセスになる可能性があります。開始時には、システムの基準値（ベースライン）を作成するために、除外するパスを定義し、システムに加えられた非標準的な変更を確定するようにシステムを構成する必要があります。

アップデートを実行する前にシステムを再チェックする手順が必要になるため、日常の運用も煩雑になります。また、ソフトウェアのバージョン変更をシステムの新しい基準値として取り込むために、システム測定の基準値を再作成または再確立する必要があります。監査レポートも別の場所に転送する必要があります。これは、システムの侵入者が足跡を消して身を隠すために監査ログを改ざんするのを防ぐ必要があるためです。

これによりシステムの管理負荷は確実に増加しますが、知らないうちにファイルが変更されていないことを確認するための数少ない確実な方法の1つです。最も人気のある侵入検知およびファイル監査システムには、Aide や Tripwireなどがあります。.

隔離された環境

個々のコンポーネントを独自の専用スペースで実行する手法は、隔離された実行環境と呼ばれます。

これは、特定のアプリケーションコンポーネントが独自の専用サーバーに配置されること、またはサービスがchroot環境（またはコンテナ）で動作するように構成されることを意味する場合があります。環境がどの程度隔離されているかは、主にインフラストラクチャの実態とアプリケーションの要件に依存します。

隔離された環境によるセキュリティの強化

プロセスを個々の環境に隔離することで、セキュリティ上の欠陥によって影響を受ける可能性のあるプロセスも隔離することになります。船の区画や隔壁が船体の破損を食い止めるのに役立つのと同様に、システムの個々の部品やコンポーネントを分離しておけば、侵入者がそのうちの1つにアクセスしたとしても、相互に接続されたネットワークシステム全体にアクセスすることはできません。

導入の難易度

アプリケーションを隔離する複雑さは、使用することに決めたコンテインメントの種類によって異なります。Dockerは隔離をセキュリティ機能とはみなしていません。しかし、コンポーネントが異なるコンテナに分割されている場合、隔離ははるかに容易に達成されます。次のチュートリアルに従って、当社のインフラストラクチャにDockerをインストールできます。.

chroot環境をセットアップする場合も、ある程度の隔離は提供されます。しかし、そのような環境から脱出する方法が存在するため、これは完全に侵入不可能な方法ではありません。さまざまなコンポーネントに専用のマシンを用意することが、通常、隔離を達成するための最善かつ最もシンプルな方法です。ただし、追加のマシンが必要になるため、コストが高くなります。

おわりに

提供された戦略は、システムのセキュリティを向上させるために実行できる手順の一部にすぎません。セキュリティ機能の導入を待てば待つほど、その効果が低下することに注意してください。それを念頭に置いて、セキュリティを後回しにしないことが重要です。代わりに、インフラストラクチャ構築の最初のプロビジョニングの1つとして実装する必要があります。ベースラインの保護によってシステムが十分に安全になったら、安全な環境でデフォルトで実行されていることを確認しながら、サービスの有効化やアプリケーションの追加を開始できます。

しかし、セキュリティは停滞したプロセスではなく、流動的なプロセスです。維持し、反復する必要があります。常に意識を持ち、持続的な警戒を怠らない姿勢で臨むべきです。システム変更に伴うセキュリティ上の影響がどのようなものであるかを常に自問してください。オペレーティング環境とデフォルト設定が常にセキュリティを最適化し、十分に防御的なソフトウェアで動作していることを確認してください。

快適なコンピューティングを！