アクセスを確認して維持
信頼できる経路でサーバーの身元を確認し、SSH公開鍵を追加してください。名前付きの管理ユーザーを作成します。新しいセッションをテストする間は元のセッションを開いたままにし、認証を変更する前に復旧方法を記録してください。
パッチ適用と露出の低減
サポート対象のセキュリティアップデートをインストールし、必要に応じて再起動してください。待ち受けサービスを確認し、IPv6 を含め必要なポートのみをファイアウォールで許可してください。未使用のデーモンを削除し、セットアップを簡単にするためだけにデータベースを公開しないでください。
ユーザーとシークレットを分離する
アプリケーションはそれぞれ専用のアカウントで実行してください。非公開の設定は公開ウェブディレクトリの外に置き、バージョン管理から除外してください。データベースの権限は狭く設定し、本番環境と実験環境で認証情報を分けてください。
動作する復旧経路を残す
ログローテーション、ディスクアラート、別個のバックアップを設定してください。一度再起動して、アプリケーションが正しく起動することを確認します。変更内容を記録し、クリーンなイメージ上で設定を再構築できるようにしてください。
セッションを閉じる前に確認する
新しいアカウントで2つ目の接続を開き、管理者権限への昇格を確認し、別のクライアントからファイアウォールをテストしてください。再起動後にサービスが復帰することを確認してください。ネットワークルールの誤りによって場当たり的な復旧を強いられることのないよう、プロバイダーの復旧経路を文書化しておいてください。
初日の確認チェックリスト
開いているソケット、最近の認証イベント、更新状況、バックアップの経過時間、ディスク使用量を確認してください。非公開の設定情報やバージョン管理のメタデータが HTTP 経由で取得できないことを確認してください。実際のワークロードを支える最小限のツールセットのみをインストールしてください。
ss -lntup
df -h
free -h
systemctl --failedアクセス変更は元に戻せる順序で行う
まずコンソールまたはレスキュー経路を確認し、信頼できるプロバイダーのチャネルを通じて SSH ホストキーを検証してください。名前付き管理者の公開鍵をインストールし、2つ目の接続を開いて特権昇格をテストしてください。サービスの再読み込み前に SSH 設定の構文を検証してください。ファイアウォールの変更は、意図した SSH 経路が許可された後にのみ適用してください。古い認証方式は、必要な第二要素フローを含め、新しいセッションで代替手段が機能することを確認してから無効化してください。
- 有効な設定とインクルードされたスニペットを確認してください。あるファイルの設定が最終的なポリシーとは限りません。
- 鍵ベースのログイン設計を検討する際は、パスワード認証とキーボードインタラクティブの両方のポリシーを確認してください。
- デフォルト以外のSSHポートはバックグラウンドのノイズを減らせますが、検証済みの鍵、アクセス制限、更新の代わりにはなりません。
- お使いのディストリビューションのサービス名と再読み込み手順を使用してください。新しいポリシーが実証されるまで、元のセッションを維持してください。
# Validate before applying a changed SSH configuration.
sudo /usr/sbin/sshd -t
# Read effective settings; adapt user, host and client address to the test.
sudo /usr/sbin/sshd -T -C user=admin,host=server.example,addr=198.51.100.10公式ドキュメント: OpenSSH：サーバー設定マニュアル
ホストの外部からファイアウォールを検証する
プロバイダーのネットワークファイアウォールとゲストのファイアウォールを、別々の制御として確認してください。別の許可されたマシンから、IPv4 と IPv6 経由で目的のサービスをテストしてください。ローカル接続は、プロセスが待ち受けていることしか証明しません。すべての ICMP パケットを無条件に拒否しないでください。通常のネットワーク運用にも適切な制御トラフィックが必要です。コンテナで公開されたポートは実際のルールと照合してください。アプリケーションの公開範囲が、ファイアウォールのフロントエンドが適用したと想定したポリシーと一致しない場合があります。
- SSH が失敗する場合は、キーを繰り返し変更する前に、送信元アドレスの制限、リッスンインターフェース、プロバイダーのファイアウォールを確認してください。
- HTTPS が失敗した場合は、DNS、プロセスのリスナー、ローカル/プロキシファイアウォールの順に確認してください。
- 最初の本番データセットを投入する前に、更新状況、クリーンな再起動、ディスクアラート、独立して復元可能なバックアップを確認してください。
- 文書化されたタイムゾーンを設定し、時刻同期を確認してください。ワークロードのメモリと保持のニーズを確認せずに、任意のスワップやログ設定を追加しないでください。
公式ドキュメント: Ubuntuサーバー：ファイアウォール管理