セキュリティ更新プログラムを自動的にインストールすることの長所と短所？
私は最近、セキュリティ更新プログラムの自動インストールに関する議論に入りました。このシステムは、小規模な非営利組織（基本的には1人または2人の管理者が自由な時間にシステムを管理する）によって使用および管理されています。通常、ユーザーがボックスに触れるのは、実行する機能の更新がある場合、または何かが機能していない場合（監視がないため、不満を言う人が発見した場合）です。
管理者がセキュリティ更新を無視するリスクが高いため、セキュリティ更新を自動化することをお勧めします（特に、他の更新ではなく、セキュリティ更新のみをインストールします）。現在、他の誰かが、深刻な管理者がソフトウェア更新の自動インストールを構成することはないと主張しています。
私が考えることができる自動化に対する考えられる理由は、私にとって大きな問題ではないようです：
- スプーフィングされた更新リポジトリー—手動で更新すると、これが発生する可能性が低くなりません。適切な署名検証があれば、これを利用するのはかなり困難です。
- システムを破壊する更新プログラム-セキュリティ更新プログラムは、ほとんどの場合、インターフェイスの互換性を維持する必要があるため、ドロップイン置換であり、自動インストールをセキュリティ更新プログラムに制限することで、このリスクは十分に軽減されます。
- 実行中のシステムでの更新によるデータの破損：適切なパッケージ化とインストールルーチンを使用すると、パッケージが適切な対策を講じることを期待します（たとえば、サービスをシャットダウンしてからアップグレードし、後で再起動します）。
- ダウンタイム：指定されたメンテナンスウィンドウの間に自動アップグレードを実行するようにスケジュールすることで制御できます。それとは別に、システムの使用率が低いため、この特定のケースでは問題は少ないと考えています。
セキュリティ更新プログラムの自動インストールに関する一般的な推奨事項は何ですか（散発的にのみ管理者の注意を引くシステムのシナリオを考慮してください）？セキュリティ更新プログラムの自動インストールによって引き起こされるリスクは何ですか？
CIS Controls（以前はTOP20 Critical Security Controlsと呼ばれていました）、特に番号＃3を見ると、 見つかります ：自動ソフトウェア更新ツールを順番に展開しますオペレーティングシステムがソフトウェアベンダーから提供された最新のセキュリティ更新を実行していることを確認します。
したがって、特に「管理者の注意力が低い」場合は、この方法をお勧めします。
リスクを十分に特定しました。最大の問題は運用上の問題です（更新には再起動が必要、更新では一部のサービスが停止するなど）。
スプーフィングされた更新リポジトリのリスクに関して、今日のほとんどの更新システムはTLS認証またはパッケージ署名、あるいはその両方に依存しており、このリスクを制限しています。このリスクは通常、パッチが適用されていない重大な脆弱性があるシステムを実行するよりも低くなります。
結局のところ、決定マトリックスでシステムのリスクエクスポージャー（インターネットエクスポージャーなど）も考慮する必要があります。
フラガは素晴らしい答えを出します。 DevOpsスピンを追加したいだけです。
既存のシステムで障害が発生する更新について深刻な懸念がある場合は、CIパイプラインを介してシステム更新を実行することで、問題を軽減できます。
これは、Dockerを使用すると比較的簡単になります。基本イメージまたは依存関係のセキュリティ更新が検出されたときに、新しいイメージのビルドを「単純に」トリガーし、自動テストを通じて新しいイメージを実行し、そのイメージを本番環境に自動的にプッシュします。
コンテナーに行かずに同様のことを行う方法はいくつかありますが、Dockerには、これをベアメタルデプロイメントやステートフルVMに比べて比較的簡単にするツールを提供するという利点があります。