サーバーを保護するための推奨されるセキュリティ対策

序章

クラウドインフラストラクチャで作業している場合、アプリケーションを起動して実行することが主な関心事になることがよくあります。セットアップと展開のプロセスの一部として、システムとアプリケーションが一般に公開される前に、堅牢で徹底的なセキュリティ対策を組み込むことが重要です。このチュートリアルでアプリケーションを展開する前にセキュリティ対策を実装すると、展開後に実装される可能性のあるアドホックな対策とは対照的に、インフラストラクチャで実行するすべてのソフトウェアが安全な基本構成になります。

このガイドでは、サーバーインフラストラクチャの構成とセットアップ中に実行できるいくつかの実用的なセキュリティ対策について説明します。このリストは、サーバーを保護するために実行できるすべてのリストではありませんが、これに基づいて構築できる開始点を提供します。時間の経過とともに、環境やアプリケーションの特定のニーズに合わせて、より調整されたセキュリティアプローチを開発できます。

SSHキー

SSH（セキュアシェル）は、サーバーの管理と通信に使用される暗号化されたプロトコルです。サーバーを操作する場合、SSHを介してサーバーに接続されているターミナルセッションでほとんどの時間を費やす可能性があります。パスワードベースのログインのより安全な代替手段であるSSHキーは、暗号化を使用してサーバーに安全にログインする方法を提供し、すべてのユーザーに推奨されます。

SSHキーを使用すると、認証の目的で秘密キーと公開キーのペアが作成されます。秘密鍵はユーザーによって秘密にされ、安全に保たれますが、公開鍵は共有できます。

SSHキー認証を構成するには、サーバーの適切なディレクトリに公開SSHキーを配置する必要があります。クライアントが最初にサーバーに接続するとき、サーバーは、関連付けられた秘密鍵を持っていることの証明を要求します。これは、ランダムな値を生成してSSHクライアントに送信することで行われます。次に、SSHクライアントは秘密鍵を使用して応答を暗号化し、暗号化された応答をサーバーに送信します。次に、サーバーは公開鍵を使用してクライアントの応答を復号化します。サーバーがランダムな値を復号化できる場合、それはクライアントが秘密鍵を所有していることを意味し、サーバーはパスワードなしで接続できるようにします。

SSHキーベースの認証がどのように機能するかについて詳しくは、SSH暗号化と接続プロセスについての記事をご覧ください。

SSHキーはどのようにセキュリティを強化しますか？

SSHを使用すると、パスワード認証を含むあらゆる種類の認証が完全に暗号化されます。ただし、パスワードベースのログインが許可されている場合、特にサーバーが公開IPアドレスを持っている場合、悪意のあるユーザーがサーバーへのアクセスを繰り返し試みる可能性があります。最新のコンピューティングパワーでは、これらの試行を自動化し、正しいパスワードが見つかるまで組み合わせを試行することで、サーバーへのエントリを取得することができます。

SSHキー認証を設定すると、パスワードベースの認証を無効にできます。 SSHキーには通常、パスワードよりもはるかに多くのデータが含まれています。つまり、攻撃者が実行しなければならない可能性のある組み合わせが大幅に多くなります。多くのSSHキーアルゴリズムは、実行可能なすべての一致を実行するのに時間がかかりすぎるため、最新のコンピューティングハードウェアでは解読できないと見なされています。

SSHキーを実装する方法

SSHキーは、Linuxサーバー環境にリモートでログインするための推奨される方法です。 SSHキーのペアをローカルマシンで生成でき、公開キーを数分以内にサーバーに転送できます。

サーバーにSSHキーを設定するには、Ubuntu、Debian、またはCentOS用のディストリビューション固有のガイドSSHキーの設定方法に従ってください。

それでもパスワード認証が必要な場合は、サーバーに fail2ban のようなソリューションを実装して、パスワードの推測を制限することを検討してください。

いずれの場合も、rootユーザーがSSH経由で直接ログインできないようにすることをお勧めします。代わりに、非特権ユーザーとしてログインし、sudoなどのツールを使用して必要に応じて特権を昇格させます。権限を制限するこのアプローチは、最小特権の原則として知られています。サーバーに接続し、SSHで動作することを確認した非特権アカウントを作成したら、サーバーの/etc/ssh/sshd_configでPermitRootLogin noディレクティブを設定することにより、rootログインを無効にできます。次に、sudo systemctl restart sshdなどのコマンドを使用してサーバーのSSHプロセスを再起動します。

ファイアウォール

ファイアウォールは、サービスがネットワークに公開される方法、および特定のサーバーに出入りできるトラフィックの種類を制御するソフトウェアまたはハードウェアデバイスです。適切に構成されたファイアウォールにより、サーバーまたはネットワークの外部から、公開されているはずのサービスにのみアクセスできるようになります。

通常のサーバーでは、デフォルトで多数のサービスが実行されている場合があります。これらは、次のグループに分類できます。

インターネット上の誰でも、多くの場合匿名でアクセスできる公共サービス。この例は、サイトへのアクセスを許可する可能性のあるWebサーバーです。
許可されたアカウントの選択されたグループまたは特定の場所からのみアクセスする必要があるプライベートサービス。たとえば、phpMyAdminのようなデータベースコントロールパネル。
パブリックインターネットにサービスを公開せずに、サーバー自体の内部からのみアクセスできる内部サービス。たとえば、ローカル接続のみを受け入れる必要があるデータベース。

ファイアウォールは、さまざまな粒度で上記のカテゴリに従ってソフトウェアへのアクセスを制限することを保証できます。公共サービスは開いたままにしてインターネットで利用でき、プライベートサービスは接続タイプなどのさまざまな基準に基づいて制限できます。内部サービスをインターネットに完全にアクセスできないようにすることができます。使用されていないポートの場合、ほとんどの構成でアクセスが完全にブロックされます。

ファイアウォールはどのようにセキュリティを強化しますか？

サービスがセキュリティ機能を実装している場合や、サービスを実行するインターフェイスに制限されている場合でも、ファイアウォールは、トラフィックがアプリケーションによって処理される前にサービスとの接続を制限することにより、保護の基本レイヤーとして機能します。

適切に構成されたファイアウォールは、開いたままにする必要がある特定のサービスを除くすべてへのアクセスを制限します。ほんの数個のソフトウェアを公開することで、サーバーの攻撃対象領域が減少し、悪用に対して脆弱なコンポーネントが制限されます。

ファイアウォールを実装する方法

Linuxシステムで利用できるファイアウォールはたくさんあり、いくつかは他よりも複雑です。ただし、一般的に、ファイアウォールの設定には数分しかかからず、サーバーの初期設定中、またはサーバーで実行されているサービスに変更を加えたときにのみ行う必要があります。起動して実行するためのいくつかのオプションは次のとおりです。

UFW（Uncomplicated Firewall）は、Ubuntuなどの一部のLinuxディストリビューションにデフォルトでインストールされています。人気のあるファイアウォールについて詳しくは、チュートリアルUbuntu20.04でUFWを使用してファイアウォールを設定する方法をご覧ください。
CentOSを使用している場合は、 CentOS8でfirewalldを使用してファイアウォールを設定する方法に従うことができます。
Iptablesの使用方法を学びたい場合は、 Iptables Essentials：一般的なファイアウォールルールとコマンドチュートリアルで、Iptablesを直接使用する方法を説明します。

DigitalOceanを使用している場合は、追加費用なしでクラウドファイアウォールを利用することもできます。これは数分でセットアップできます。

ここで説明するチュートリアルのいずれかを使用して、ファイアウォール構成がデフォルトで不明なトラフィックをブロックしていることを確認してください。そうすれば、展開する新しいサービスが誤ってインターネットに公開されることはありません。代わりに、アクセスを明示的に許可する必要があります。これにより、サービスの実行方法、アクセス方法、およびサービスを使用できるユーザーを評価する必要があります。

VPCネットワーク

仮想プライベートクラウド（VPC）ネットワークは、インフラストラクチャのリソース用のプライベートネットワークです。ネットワークのインターフェイスはパブリックインターネットやクラウド内の他のVPCネットワークからアクセスできないため、VPCネットワークはリソース間のより安全な接続を提供します。

VPCネットワークはどのようにセキュリティを強化しますか

VPCネットワークではリソースのグループを特定のプライベートネットワークに分離できるため、内部通信にパブリックネットワークではなくプライベートネットワークを使用することをお勧めします。 VPCネットワークは、内部ネットワークを介してプライベートネットワークインターフェイスを使用してのみ相互に接続します。つまり、システム間のトラフィックは、公開または傍受される可能性のあるパブリックインターネットを介してルーティングされません。 VPCネットワークを使用して、実行環境とテナントを分離することもできます。

さらに、VPCネットワークのリソースとパブリックインターネット間の単一のアクセスポイントとしてインターネットゲートウェイを設定できるため、リソースに接続するパブリックトラフィックをより詳細に制御および可視化できます。

VPCネットワークを実装する方法

多くのクラウドインフラストラクチャプロバイダーでは、データセンター内のVPCネットワークにリソースを作成して追加できます。

DigitalOceanを使用していて、独自のVPCゲートウェイをセットアップしたい場合は、ドロップレットをVPCゲートウェイとして構成する方法ガイドに従って、Debian、Ubuntu、およびCentOSベースのサーバーでの方法を学ぶことができます。

DigitalOceanは、追加費用なしで、作成時に VPCに該当する各リソース（ドロップレット、ロードバランサー、Kubernetesクラスター、データベース）を配置します

独自のプライベートネットワークを手動で構成するには、高度なサーバー構成とネットワークの知識が必要になる場合があります。 VPCネットワークを設定する代わりに、サーバー間でVPN接続を使用することもできます。 UbuntuまたはCentOSを使用している場合は、この Ubuntu20.04でOpenVPNサーバーをセットアップおよび構成する方法チュートリアルに従うことができます。

Ubuntuサーバー間のより複雑でないVPNについては、このTincをインストールしてUbuntu18.04に基本的なVPNをセットアップする方法チュートリアルに従ってください。

サービス監査

セキュリティの大部分は、システムの分析、利用可能な攻撃対象領域の理解、およびコンポーネントの可能な限りのロックダウンに関係しています。

サービス監査は、特定のシステムで実行されているサービス、通信に使用されているポート、および受け入れられているプロトコルを知る方法です。この情報は、パブリックアクセス可能にするサービス、ファイアウォール設定、および監視とアラートを構成するのに役立ちます。

サービス監査はどのようにセキュリティを強化しますか？

サーバーは、内部目的および外部クライアントを処理するためにプロセスを実行できます。実行中の各サービスは、それが内部または公開を目的としているかどうかにかかわらず、悪意のあるユーザーに対する拡張された攻撃対象領域を表します。実行しているサービスが多いほど、ソフトウェアに影響を与える脆弱性の可能性が高くなります。

マシンで実行されているネットワークサービスがわかったら、これらのサービスの分析を開始できます。サービス監査を実行するときは、実行中の各サービスについて次の質問を自問してください。

このサービスを実行する必要がありますか？
サービスは、実行すべきではないネットワークインターフェイスで実行されていますか？
サービスをパブリックまたはプライベートネットワークインターフェイスにバインドする必要がありますか？
ファイアウォールルールは、正当なトラフィックをこのサービスに渡すように構成されていますか？
ファイアウォールルールが正当でないトラフィックをブロックしていますか？
これらの各サービスの脆弱性に関するセキュリティアラートを受信する方法はありますか？

このタイプのサービス監査は、インフラストラクチャに新しいサーバーを構成する際の標準的な方法です。数か月ごとにサービス監査を実行すると、意図せずに変更された可能性のある構成を持つサービスを検出するのにも役立ちます。

サービス監査の実行方法

システムで実行されているネットワークサービスを監査するには、ssコマンドを使用して、サーバーで使用されているすべてのTCPポートとUDPポートを一覧表示します。 TCPおよびUDPトラフィックのリッスンに使用されているプログラム名、PID、およびアドレスを示すコマンドの例は次のとおりです。

sudo ss -plunt

次のような出力が表示されます。

OutputNetid       State        Recv-Q       Send-Q             Local Address:Port             Peer Address:Port      Process
tcp         LISTEN       0            128                      0.0.0.0:22                    0.0.0.0:*         users:(("sshd",pid=812,fd=3))
tcp         LISTEN       0            511                      0.0.0.0:80                    0.0.0.0:*         users:(("nginx",pid=69226,fd=6),("nginx",pid=69225,fd=6))
tcp         LISTEN       0            128                         [::]:22                       [::]:*         users:(("sshd",pid=812,fd=4))
tcp         LISTEN       0            511                         [::]:80                       [::]:*         users:(("nginx",pid=69226,fd=7),("nginx",pid=69225,fd=7))

注意が必要な主な列は、Netid、Local Address：Port、およびProcessnameの列です。ローカルアドレス：ポートが0.0.0.0の場合、サービスはすべてのIPv4ネットワークインターフェイスで接続を受け入れています。アドレスが[::]の場合、サービスはすべてのIPv6インターフェイスで接続を受け入れています。上記の出力例では、SSHとNginxは両方とも、IPv4とIPv6の両方のネットワークスタック上のすべてのパブリックインターフェイスでリッスンしています。

この出力例を使用して、SSHとNginxが両方のインターフェースでリッスンすることを許可するか、どちらか一方のみでリッスンすることを許可するかを決定できます。通常、未使用のインターフェイスで実行されているサービスを無効にする必要があります。たとえば、サイトにIPv4経由でのみアクセスできるようにする必要がある場合は、サービスがIPv6インターフェイスでリッスンするのを明示的に禁止して、公開されるサービスの数を減らします。

無人更新

サーバーをパッチで最新の状態に保つことは、優れた基本レベルのセキュリティを確保するために必須です。古くて安全でないバージョンのソフトウェアを実行しているサーバーが侵害の大部分の原因ですが、定期的な更新により脆弱性を軽減し、攻撃者がサーバーに足を踏み入れるのを防ぐことができます。

従来の更新では、管理者がサーバー上のさまざまなパッケージの更新を手動で確認してインストールする必要があります。これには時間がかかる可能性があり、メジャーアップデートを忘れたり見逃したりする可能性があります。対照的に、無人更新では、システムがパッケージの大部分を自動的に更新できます。

無人更新はどのようにセキュリティを強化しますか？

無人更新を実装すると、サーバーを安全に保つために必要な労力のレベルが下がり、サーバーが既知のバグに対して脆弱になる可能性がある時間が短縮されます。サーバー上のソフトウェアに影響を与える脆弱性が発生した場合、更新の実行にかかる時間にかかわらず、サーバーは脆弱になります。毎日の無人アップグレードにより、パッケージを見逃すことはなく、修正が利用可能になるとすぐに脆弱なソフトウェアにパッチが適用されます。

前述のサービス監査と組み合わせて、更新を自動的に実行することで、攻撃への露出を大幅に減らし、サーバーのセキュリティの維持に費やす時間を短縮できます。

無人更新を実装する方法

現在、ほとんどのサーバーディストリビューションは、オプションとして無人更新を備えています。たとえば、Ubuntuでは、管理者は次を実行できます。

sudo apt install unattended-upgrades

無人更新を実装する方法の詳細については、 Ubuntu （自動更新の下）およびFedoraのこれらのガイドを確認してください。

注：これらのメカニズムは、システムのパッケージマネージャーを介してインストールされたソフトウェアのみを自動更新します。 Webアプリケーションのように実行している可能性のある追加のソフトウェアは、自動更新用に構成されているか、定期的に手動でチェックされていることを確認してください。

ディレクトリインデックスを無効にする

ほとんどのWebサーバーは、ユーザーがインデックスファイルのないディレクトリにアクセスしたときにディレクトリインデックスを表示するようにデフォルトで構成されています。たとえば、追加の構成を行わずにWebサーバー上にdownloadsというディレクトリを作成した場合、ディレクトリを参照しているすべてのユーザーにすべてのファイルが表示されます。多くの場合、これはセキュリティ上の懸念事項ではありませんが、機密情報が公開される可能性が非常に高くなります。たとえば、Webサーバー上にWebサイトのインデックスディレクトリを作成する場合、ディレクトリには、Webサイトのホームページのファイルと、Webサイトのバックエンドデータベースへの資格情報を含む構成ファイルが含まれる場合があります。ディレクトリのインデックスを無効にしないと、フォルダ内の両方のファイルがディレクトリを閲覧しているすべての人に表示されます。

ディレクトリインデックスを無効にすると、セキュリティはどのように強化されますか？

ディレクトリインデックスには正当な目的がありますが、意図せずに訪問者にファイルを公開することがよくあります。 Webサーバーのデフォルトとしてディレクトリインデックスを無効にすると、訪問者がディレクトリファイルを非表示にすることで、偶発的なデータの損失、漏洩、または悪用のリスクを排除できます。訪問者は、ファイルがディレクトリに存在する場合でもファイルにアクセスできますが、インデックス作成を無効にすると、意図せずにファイルを見つけるのがはるかに困難になります。

ディレクトリインデックスを無効にする方法

ほとんどの場合、ディレクトリインデックスを無効にするには、Webサーバー構成に1行追加するだけです。

Nginxはデフォルトでディレクトリインデックスを無効にしているため、Nginxを使用している場合は、変更を加える必要はありません。
Apache WikiのDirectoryListingsページでは、ディレクトリリストを無効にする方法について説明しています。 Apache Directory構成ブロックには、必ずそこにリストされているOptions -Indexesオプションを使用してください。

頻繁にバックアップする

厳密にはセキュリティ対策ではありませんが、バックアップは、侵害されたシステムとデータを保存し、システムがどのように侵害されたかを分析する上で非常に重要です。たとえば、サーバーがランサムウェア（ファイルを暗号化し、攻撃者に多額の金が支払われた場合にのみファイルを復号化する悪意のあるツールまたはウイルス）によって侵害された場合、バックアップがないことが唯一の選択肢となる可能性があります。データを取り戻すためにお金を払うことです。システムとデータが定期的かつ安全にバックアップされている場合は、侵害されたシステムと対話することなく、データにアクセスして回復することができます。

頻繁なバックアップはどのようにセキュリティを強化しますか？

頻繁なバックアップは、誤って削除した場合や、データが削除または破損した攻撃が発生した場合にデータを回復するのに役立ちます。いずれの場合も、誤って削除する前または攻撃が発生する前のデータのコピーを保持することにより、データ損失のリスクを軽減するのに役立ちます。

ランサムウェアの場合に加えて、定期的なバックアップは、長期的な攻撃のフォレンジック分析に役立ちます。データの履歴がない場合、攻撃がいつ開始され、どのデータが侵害されたかを判断するのは困難または不可能ですらあります。

頻繁なバックアップを実装する方法

システムのバックアップを実装するときは、侵害されたデータまたは削除されたデータの検証可能なリカバリを目標として扱います。自問してみてください。サーバーが明日消えた場合、最小限の作業でサーバーを安全に稼働させるためにどのような手順を実行する必要がありますか？

災害復旧計画を作成する際に考慮すべきその他の質問をいくつか示します。

最新のバックアップを常に使用する必要がありますか？データが変更される頻度と、侵害または削除が発生するタイミングによっては、代わりに古いバックアップをデフォルトにするリスクが軽減される場合があります。
バックアップを復元するための実際のプロセスは何ですか？新しいサーバーを作成する必要がありますか、それとも既存のサーバーを復元する必要がありますか？
このサーバーが動作していなくても、どれくらい生き残ることができますか？
オフサイトバックアップが必要ですか？

DigitalOcean Dropletsを使用している場合は、このガイドに従って、コントロールパネルから毎週のバックアップを有効にできます。

Restic Backup Clientを使用してデータをオブジェクトストレージサービスにバックアップする方法は、バックアップを暗号化して本番システムから保存する独自のバックアップシステムを設計するために使用できるチュートリアルです。このチュートリアルは、サーバー、またはローカルのデスクトップコンピューターやラップトップコンピューターでも機能します。

VPNとプライベートネットワーキング

プライベートネットワークは、特定のサーバーまたはユーザーのみが利用できるネットワークです。 VPN（仮想プライベートネットワーク）は、リモートコンピューター間に安全な接続を作成し、ローカルプライベートネットワークであるかのように接続を提示する方法です。これにより、サービスをプライベートネットワーク上にあるかのように構成し、安全な接続を介してリモートサーバーに接続する方法が提供されます。

たとえば、DigitalOceanプライベートネットワークは、同じアカウント内のサーバーまたは同じリージョン内のチーム間の分離された通信を可能にします。

彼らはどのようにセキュリティを強化しますか？

内部通信には、パブリックネットワークではなくプライベートネットワークを使用することをお勧めします。ただし、データセンター内の他のユーザーは同じネットワークにアクセスできるため、サーバー間の通信を保護するための追加の対策を実装する必要があります。

VPNを使用することは、事実上、サーバーだけが見ることができるプライベートネットワークを計画する方法です。通信は完全にプライベートで安全になります。他のアプリケーションは、VPNソフトウェアが公開する仮想インターフェイスを介してトラフィックを渡すように構成できます。このように、パブリックインターネット上のクライアントが利用できるようになっているサービスのみをパブリックネットワークに公開する必要があります。

これを実装するのはどれくらい難しいですか？

この機能を備えたデータセンターでプライベートネットワークを使用するのは、サーバーの作成中にインターフェイスを有効にし、プライベートネットワークを使用するようにアプリケーションとファイアウォールを構成するのと同じくらい簡単です。データセンター全体のプライベートネットワークは、同じネットワークを使用する他のサーバーとスペースを共有することに注意してください。

VPNに関しては、初期設定はもう少し複雑ですが、セキュリティの強化はほとんどのユースケースにとって価値があります。 VPN上の各サーバーには、安全な接続を確立して構成するために必要な共有セキュリティおよび構成データが必要です。 VPNが稼働した後、VPNトンネルを使用するようにアプリケーションを構成する必要があります。インフラストラクチャを安全に接続するためのVPNの設定については、OpenVPNチュートリアルをご覧ください。

公開鍵インフラストラクチャとSSL/TLS暗号化

公開鍵インフラストラクチャ（PKI）は、個人を識別し、通信を暗号化するための証明書を作成、管理、および検証するように設計されたシステムを指します。 SSLまたはTLS証明書を使用して、さまざまなエンティティを相互に認証できます。認証後、暗号化された通信を確立するために使用することもできます。

彼らはどのようにセキュリティを強化しますか？

認証局（CA）を確立し、サーバーの証明書を管理することで、インフラストラクチャ内の各エンティティが他のメンバーのIDを検証し、トラフィックを暗号化できます。これにより、攻撃者がインフラストラクチャ内のサーバーを模倣してトラフィックを傍受する中間者攻撃を防ぐことができます。

各サーバーは、一元化された認証局を信頼するように構成できます。その後、当局が署名する証明書はすべて暗黙的に信頼できます。通信に使用しているアプリケーションとプロトコルがTLS/SSL暗号化をサポートしている場合、これはVPNトンネル（内部でもSSLを使用することが多い）のオーバーヘッドなしでシステムを暗号化する方法です。

これを実装するのはどれくらい難しいですか？

認証局の構成と残りの公開鍵インフラストラクチャのセットアップには、かなりの初期作業が必要になる場合があります。さらに、証明書を管理すると、新しい証明書を作成、署名、または取り消す必要がある場合に、追加の管理負担が発生する可能性があります。

多くのユーザーにとって、本格的な公開鍵インフラストラクチャを実装することは、インフラストラクチャのニーズが高まるにつれてより理にかなっています。 VPNを使用してコンポーネント間の通信を保護することは、PKIが追加の管理コストに見合うポイントに到達するまでの適切な一時的な手段となる可能性があります。

独自の認証局を作成する場合は、使用しているLinuxディストリビューションに応じて、認証局（CA）の設定と構成の方法ガイドのいずれかを参照できます。

ファイル監査および侵入検知システム

ファイル監査は、システムが正常な状態にあるときに、現在のシステムをファイルの記録およびシステムのファイル特性と比較するプロセスです。これは、許可された可能性のあるシステムへの変更を検出するために使用されます。

侵入検知システム（IDS）は、システムまたはネットワークの不正なアクティビティを監視するソフトウェアです。多くのホストベースのIDS実装は、システムが変更されたかどうかをチェックする方法としてファイル監査を使用します。

彼らはどのようにセキュリティを強化しますか？

上記のサービスレベルの監査と同様に、安全なシステムの確保を真剣に考えている場合は、システムのファイルレベルの監査を実行できると非常に便利です。これは、管理者が定期的に実行することも、IDSの自動化されたプロセスの一部として実行することもできます。

これらの戦略は、ファイルシステムが一部のユーザーまたはプロセスによって変更されていないことを完全に確認するための唯一の方法の一部です。多くの理由で、侵入者は、サーバーを長期間悪用し続けることができるように、隠れたままにしておきたいことがよくあります。バイナリを侵害されたバージョンに置き換える可能性があります。ファイルシステムの監査を行うと、ファイルのいずれかが変更されているかどうかがわかり、サーバー環境の整合性に自信を持つことができます。

これを実装するのはどれくらい難しいですか？

IDSの実装またはファイル監査の実施は、非常に集中的なプロセスになる可能性があります。初期構成では、サーバーに加えた非標準の変更について監査システムに通知し、ベースライン読み取り値を作成するために除外する必要があるパスを定義します。

また、日常業務がより複雑になります。更新を実行する前にシステムを再チェックし、更新の実行後にベースラインを再作成してソフトウェアバージョンの変更をキャッチする必要があるため、更新手順が複雑になります。また、侵入者が自分のトラックをカバーするように監査を変更できないように、レポートを別の場所にオフロードする必要があります。

これにより管理負荷が増大する可能性がありますが、システムを正常なコピーと照合できることは、ユーザーの知らないうちにファイルが変更されていないことを確認する唯一の方法の1つです。一般的なファイル監査/侵入検知システムには、TripwireとAideがあります。

分離された実行環境

実行環境の分離とは、個々のコンポーネントが専用のスペース内で実行される方法を指します。

これは、個別のアプリケーションコンポーネントを独自のサーバーに分離することを意味する場合もあれば、chroot環境またはコンテナーで動作するようにサービスを構成することを指す場合もあります。分離のレベルは、アプリケーションの要件とインフラストラクチャの現実に大きく依存します。

彼らはどのようにセキュリティを強化しますか？

プロセスを個々の実行環境に分離すると、発生する可能性のあるセキュリティ問題を分離する能力が向上します。バルクヘッドとコンパートメントが船の船体の破損を封じ込めるのに役立つのと同様に、個々のコンポーネントを分離すると、侵入者がインフラストラクチャの他の部分にアクセスするのを制限できます。

これを実装するのはどれくらい難しいですか？

選択した包含のタイプに応じて、アプリケーションの分離はさまざまなレベルの複雑さを持つ可能性があります。個々のコンポーネントをコンテナーにパッケージ化することで、ある程度の分離をすばやく実現できますが、Dockerはコンテナー化をセキュリティ機能とは見なしていないことに注意してください。

各ピースにchroot環境を設定すると、ある程度の分離も可能になりますが、chroot環境から抜け出す方法が多いため、これも絶対確実な分離方法ではありません。コンポーネントを専用マシンに移動することは、最高レベルの分離であり、多くの場合、最も複雑ではないかもしれませんが、追加のマシンが必要になるため、追加のコストが発生します。

結論

このチュートリアルで概説されている戦略は、システムのセキュリティを向上させるために実行できるいくつかの手順の概要です。セキュリティ対策は、実装を待つ時間が長くなるほど効果が低下することを認識することが重要です。したがって、セキュリティは後から考えるべきではなく、インフラストラクチャを最初にプロビジョニングするときに実装する必要があります。構築するための安全な基盤ができたら、デフォルトで安全な環境で実行されていることを保証して、サービスとアプリケーションの展開を開始できます。

安全な開始環境であっても、セキュリティは継続的で反復的なプロセスであることに注意してください。優れたセキュリティには、絶え間ない警戒と意識の考え方が必要です。変更によるセキュリティへの影響と、ソフトウェアの安全なデフォルト構成と環境を常に作成するために実行できる手順を常に自問してください。