• 層のセキュリティ
• 不明瞭さによるセキュリティの排除
• 攻撃面の減少
• 外部システム

硬化 - 一般的な概念

一般的なハードニングのガイドラインは、ハードニングに関する主な文書に概説されています。

以下の文書では、GitLabインスタンス・ハードニングの基本的な考え方をまとめています。GitLabを参照していますが、多くの場合、これらは実際にはすべてのコンピュータシステムに適用できます。

層のセキュリティ

もしセキュリティを実装する方法が2つあるのであれば、1つだけではなく、両方の方法を実装すべきです。簡単な例は、アカウントセキュリティです：

• アカウントには、長くて複雑でユニークなパスワードを使いましょう。
• セキュリティ強化のため、認証プロセスに第二の要素を導入してください。
• 第二要素としてハードウェアトークンを使用します。
• 認証に失敗したアカウントを（少なくとも一定時間）ロックアウトします。
• 一定時間未使用のアカウントは無効にし、自動化または定期的な監査でこれを強制します。

リストの1つか2つの項目だけを使うのではなく、できるだけ多くの項目を使いましょう。この考え方は、アカウントセキュリティ以外の分野にも適用できます。

不明瞭さによるセキュリティの排除

曖昧さによるセキュリティとは、潜在的な攻撃者がその詳細を利用して攻撃を仕掛けるかもしれないという恐れから、システム、サービス、プロセスの特定の要素について議論しないことを意味します。その代わりに、システムは、その設定に関する詳細が公開されても、システムが可能な限り安全であるという点で、セキュリティが確保されるべきです。要するに、攻撃者がコンピュータ・システムの設定の詳細を知ったとしても、彼らに有利になることはないのです。不明瞭さによるセキュリティの弊害の1つは、システムの管理者がシステムを実際よりも安全だと思い込むことで、潜在的な誤ったセキュリティ意識につながる可能性があることです。

この例として、非標準のTCPポートでサービスを実行することが挙げられます。例えば、サーバーのデフォルトのSSHデーモンポートはTCPポート22ですが、TCPポート2222のような別のポートでSSHデーモンを実行するように設定することが可能です。これを設定した管理者は、これでシステムのセキュリティが高まったと思うかもしれませんが、攻撃者がシステムをポートスキャンして開いているポートをすべて発見することはよくあることで、SSHサービスをすばやく発見することができ、セキュリティ上の利点はなくなります。

GitLabはオープンコアのシステムであり、設定オプションはすべて文書化されて公開されています。これらのハードニングの推奨は公開することを意図しており、不明瞭さによるセキュリティを排除する手助けをするものです。

攻撃面の減少

GitLabは多くのコンポーネントを持つ大規模なシステムです。セキュリティの一般的なルールとして、使われていないシステムは無効にしておくことが有効です。こうすることで、潜在的な攻撃者が攻撃するために利用できる “攻撃対象領域 “をなくすことができます。また、利用可能なシステムリソースを増やすという利点もあります。

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

外部システム

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