強化 - 一般的な概念

一般的な強化ガイドラインは、メインの強化ドキュメントに概説されています。

次のドキュメントは、GitLabインスタンスの強化に関する根本的な哲学の一部を要約したものです。多くの場合、これらはすべてのコンピューターシステムに実際に適用できます。

レイヤー化されたセキュリティ

セキュリティを実装する方法が2つある場合、どちらか一方ではなく両方を実装する必要があります。簡単な例としては、アカウントセキュリティがあります:

アカウントに長く、複雑で、一意のパスワードを使用してください。
セキュリティ強化のために、認証プロセスにセカンドファクターを実装します。
ハードウェアトークンをセカンドファクターとして使用します。
失敗した認証試行に対して、アカウントを（少なくとも一定期間）ロックアウトします。
特定の期間使用されていないアカウントは無効にする必要があり、これは自動化または定期的な監査のいずれかで強制されます。

リストにある項目のうち1つか2つだけを使用するのではなく、できるだけ多く使用してください。この哲学は、アカウントセキュリティ以外の他の領域にも適用できます。可能な限りすべての領域に適用すべきです。

隠蔽によるセキュリティの排除

隠蔽によるセキュリティとは、潜在的な攻撃者がその詳細を利用して攻撃を仕掛けることを恐れ、システム、サービス、またはプロセスの特定の要素について議論しないことを意味します。そうではなく、設定に関する詳細が公開されていてもシステムの安全性が維持されるレベルまでセキュリティを確保すべきです。つまり、攻撃者がコンピューターシステムの設定の詳細を知ったとしても、それが攻撃者にとって有利にならないようにするということです。隠蔽によるセキュリティの欠点の1つは、システム管理者が実際よりもシステムが安全であると思い込み、誤った安心感を抱く可能性があることです。

その一例として、非標準のTCPポートでサービスを実行することが挙げられます。たとえば、サーバー上のSSHデーモンのデフォルトポートはTCPポート22ですが、SSHデーモンをTCPポート2222などの別のポートで実行するよう設定することも可能です。この設定を行った管理者はシステムのセキュリティが向上したと考えるかもしれません。しかし、攻撃者がシステムをポートスキャンして開いているすべてのポートを検出することは非常に一般的であり、SSHサービスはすぐに発見され、認識されていたセキュリティ上の優位性は失われます。

GitLabはオープンコアシステムであり、すべての設定オプションは十分にドキュメント化された公開情報であるため、隠蔽によるセキュリティという考え方はGitLabのコアバリューである透明性に反します。これらの堅牢化に関する推奨事項は、隠蔽によるセキュリティを排除するために公開されています。

アタックサーフェスの削減

GitLabは多くのコンポーネントを持つ大規模なシステムです。セキュリティの一般的なルールとして、未使用のシステムは無効にすると役立ちます。これにより、潜在的な攻撃者が利用できる「アタックサーフェス」が排除されます。これにより、利用可能なシステムリソースが増加するという追加の利点も得られます。

例として、5分ごとに起動してキューの入力をチェックし、チェックを実行しながら複数のサブプロセスをクエリするシステム上のプロセスがあります。そのプロセスを使用していない場合、それを設定しておく理由はなく、無効にするべきです。もし攻撃者がこのプロセスを使用する脅威ベクターを発見した場合、たとえあなたの組織がそれを使用していなくても、攻撃者はそれを悪用する可能性があります。一般的なルールとして、使用されていないサービスはすべて無効にする必要があります。

外部システム

より大規模でありながらも強化されたデプロイでは、GitLabのデプロイが必要とする負荷を処理するために、しばしばマルチノードが使用されます。そのような場合は、外部、オペレーティングシステム、およびファイアウォールルールのための設定オプションの組み合わせを使用します。制限を使用するいかなるオプションも、サブシステムが機能するのに十分なだけ開かれるべきです。可能な場合は常に、ネットワークトラフィックにTLS暗号化を使用します。