Amazonコレクションから、Amazon EC2にfedora Linux AMIをインストールしました。EBSストレージに接続する予定です。最も基本的な手順しか行っておらず、パスワードも変更されておらず、この段階では上記以外に何もしていないと仮定します。
この時点から、ハッカーを阻止してインスタンス/EBS を保護するには、どのような手順を踏む必要がありますか?
Amazonコレクションから、Amazon EC2にfedora Linux AMIをインストールしました。EBSストレージに接続する予定です。最も基本的な手順しか行っておらず、パスワードも変更されておらず、この段階では上記以外に何もしていないと仮定します。
この時点から、ハッカーを阻止してインスタンス/EBS を保護するには、どのような手順を踏む必要がありますか?
実際、ここでは他の Linux サーバーを保護するのと何ら違いはありません。
ある時点で、独自のイメージ (AMI) を作成する必要があります。これを行う理由は、インスタンスがダウンすると、既存の AMI に加えた変更が失われるためです (Amazon はインスタンスが無期限にアクティブであるとは保証していないため、簡単に発生する可能性があります)。データ ストレージに EBS を使用している場合でも、インスタンスがダウンするたびに、OS を構成する同じ日常的なタスクを実行する必要があります。また、特定の期間にインスタンスを停止して再起動したり、トラフィックがピークの場合に複数のインスタンスを開始したりすることもできます。
ドキュメントで、イメージを作成するためのいくつかの手順を読むことができます。セキュリティに関しては、証明書ファイルとキーを公開しないように注意する必要があります。これに失敗すると、クラッカーがそれらを使用して、課金される新しいインスタンスを開始する可能性があります。ありがたいことに、プロセスは非常に安全であり、いくつかの点にのみ注意を払う必要があります。
私たちが仕事で行ったことは、パスワードではなく秘密鍵だけでサーバーにアクセスできることを確認したことです。また、ping を無効にして、サーバーに ping を送信する人が私たちのサーバーを見つける可能性を低くしました。さらに、週末に自宅からアクセスする必要がある数人の IT 担当者を除いて、ポート 22 をネットワーク IP 以外からブロックしました。その他の重要でないポートはすべてブロックされました。
EC2 インスタンスが複数ある場合は、サーバー間の相互通信が安全であることを確認する方法を見つけることをお勧めします。たとえば、サーバー A が侵害されたという理由だけで、サーバー B もハッキングされるのは望ましくありません。あるサーバーから別のサーバーへの SSH アクセスをブロックする方法があるかもしれませんが、私は個人的にこれを行っていません。
EC2 インスタンスの保護が社内サーバーよりも難しいのは、企業のファイアウォールがないことです。代わりに、Amazon が提供するツールのみに依存します。サーバーが社内にあったとき、一部のサーバーはインターネットに公開されておらず、ネットワーク内でしかアクセスできませんでした。これは、サーバーにパブリック IP アドレスがなかったためです。