検証済みのアクセスとリカバリ経路から始め、次に個別の管理、テスト済みのSSHキー、制限的なファイアウォール、維持されたソフトウェア、独立したバックアップを構成します。変更は段階的に適用し、古いセッションを閉じる前に新しいセッションを検証してください。
信頼できる出発点を確立する
マシンを変更する前に、予想されるオペレーティングシステム、アクセス方法、リカバリ経路を確認してください。予期しないキーを調査せずに受け入れるのではなく、オペレーターの承認された情報を通じてSSHホストの身元を検証してください。一時的な認証情報は非公開にし、意図されたプロセスを通じて交換してください。誰がメンテナンスに責任を持つか、このサービスで実際に利用可能なリカバリオプションは何かを記録してください。
アクセス変更を行う間は、動作中の管理セッションを開いたままにしてください。コピーされたハードニングレシピは、異なるディストリビューションやアカウントレイアウトを想定している場合、唯一使用可能なログインを削除する可能性があります。一度に1つの変更を行い、その有効な結果を確認し、戻り道を保持してください。目標は、厳格に見えても管理できない構成ではなく、安全に維持できるシステムです。
SSHアクセスを意図的にする
1つの永続的なrootログインを共有するのではなく、適切な権限を持つ個別の管理アクセスを作成します。意図した公開鍵をインストールしてテストし、秘密鍵は認可されたエンドポイントに保管します。Ubuntu OpenSSHのドキュメントでは、サーバー設定と認証の選択肢について説明されています。1つの設定を編集すればサービス全体が変更されたと決めつける前に、インクルードファイルを含む、お使いのディストリビューションの有効な設定を確認してください。
パスワード認証や特権ログインのルールを変更する前に、2つ目のセッションで鍵アクセスをテストします。新しいアカウントが必要な管理作業を実行できることを確認します。以前の方法に依存している自動化を確認し、そのアクセスを意図的に置き換えます。鍵はアクセス資格情報であるため、アプリケーションディレクトリ内にコピーを残すのではなく、プライベートな保管場所とローテーション手順を使用してください。
マシン全体ではなくアプリケーションを公開する
リッスンしているサービスを洗い出し、どれを公開する必要があるかを特定します。WebアプリケーションはHTTPとHTTPSを必要とする場合がありますが、そのデータベースは意図した内部パス経由でのみ到達可能なままにできます。Ubuntuはファイアウォール設定ツールとしてUFWを説明していますが、有用なポリシーはツールに依存しません。必要なトラフィックを許可し、実用的な範囲で管理アクセスを承認された送信元に制限します。
サービスにホストレベルとプロバイダーレベルの両方の制御が含まれる場合は、両方を確認します。制限の厳しいルールセットを有効にする前に、テスト済みの管理パスを許可し、別のセッションからアクセスを検証します。SSHを別のポートに移動しても認証やパッチ適用の代わりにはならないと想定しないでください。ファイアウォールルールは理解しやすいものにしておき、将来のトラブルシューティングで回避策としてすべてのポートを開くことにならないようにします。
| 変更 | 適用前に確認 | 適用後に確認 |
|---|---|---|
| 新しいSSH鍵 | 正しいアカウントと公開鍵 | 2つ目の鍵認証セッションが機能する |
| 制限されたファイアウォール | 必要なサービスと復旧パス | 公開アプリが機能し、意図しないポートが閉じている |
| ソフトウェア更新 | バックアップと再起動への影響 | サービスが再起動し、アプリケーションテストに合格する |
| サービス権限の変更 | 必要な読み取りおよび書き込みパス | より広範なシステムアクセスなしでアプリが機能する |
更新を運用プロセスとして計画する
システムとアプリケーションの依存関係を維持します。Ubuntuの自動更新ガイダンスでは、無人アップグレード、許可されたオリジン、再起動の動作について説明されています。サードパーティのリポジトリは、マシンに追加されたという理由だけで自動的に対象になるわけではありません。設定された更新プロセスが実際に何を含むかを確認し、個別にインストールされたアプリケーションには独自のメンテナンスパスを用意してください。
サービスの再起動とリブートをどのように処理するかを決定します。パッケージ更新を適用しても、実行中のすべてのプロセスが新しいコードを使用しているとは限りません。ワークロードが要求する場合はメンテナンスウィンドウを使用し、その後で簡単なアプリケーション確認を行います。パッケージに手動の移行手順が必要な場合は、すべての更新を無期限に無効化して結果として生じる露出を忘れるのではなく、手順を文書化してください。
アプリケーションアクセスを制限し、リカバリを保護する
サービスは必要な権限で実行し、公開コンテンツをシークレットやデプロイメントメタデータから分離します。Webプロセスがすべてのシステム設定を書き換えられるべきではありません。環境シークレットは公開配信ディレクトリの外に保管し、意図的な保護ポリシーなしにログ、サポートエクスポート、一般的なバックアップに含めないようにします。運用上の目的がない未使用のパッケージとサービスは削除します。
独立したバックアップを維持し、アプリケーションを分離環境に復元するテストを行います。バックアップ資格情報を制限し、侵害されたアプリケーションがすべての復旧コピーを自動的に削除できないようにします。ディスク容量、バックアップの経過時間、サービスの障害を監視します。ログは定義された運用上の問いに答えるものであるべきで、アクセスと保持は制御される必要があります。機密性の高いリクエストの無制限のコピーになってはなりません。
レビュー可能なままの初回デプロイシーケンス
新しいVPSでは、まずアクセスと復旧を確認し、次に管理アカウントとテスト済みの鍵を確立します。ファイアウォールを設定し、更新を適用し、意図したサービスアカウントでアプリケーションをデプロイします。別の環境から公開動作を確認し、プライベートファイルが取得できないことを確認し、バックアップ復元を実行します。各決定とアクセス変更を元に戻すためのパスについてメモを残します。
Vector VPS、Pulse NVMe、および選択された専用プランは、SwissOctetカタログでLinuxの選択肢を提示します。注文前に、選択したイメージとメンテナンス作業の分担を確認してください。Linuxのイメージ名だけでは、ハードニング、更新、バックアップがすでに管理されていることを証明できません。ベースラインとは、プロジェクトの変化に応じて設定、検証、維持し続ける一連の制御です。
実践チェックリスト。
- SSHホストのIDと復旧ルートを確認します。
- 2つ目のセッションで個別の鍵アクセスをテストします。
- リッスンしているサービスとファイアウォールルールを制限します。
- 更新の適用範囲と再起動の動作を確認します。
- シークレットを公開ファイルとサービス権限から分離します。
- 独立した復旧コピーをテストします。
重要な詳細。
パスワードログインをすぐに無効にすべきですか？+
まず、代替の鍵アクセスと復旧ルートを確立してテストします。その後、サポートされている設定に従って認証を変更します。
SSHのポート変更はハードニングの代わりになりますか？+
いいえ。強力な認証、制限されたアクセス、更新、適切なアカウント権限の代わりにはなりません。
自動更新はすべてのアプリケーションに十分ですか？+
いいえ。許可されたリポジトリ、再起動の要件、システムの更新プロセス外でインストールされたソフトウェアを確認してください。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- Ubuntu Server: OpenSSHサーバー ubuntu.com
- Ubuntu Server: ファイアウォール ubuntu.com
- Ubuntu Server: 自動更新 ubuntu.com
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。