セキュリティアーキテクチャ

なぜ

広範な権限は、保護されたリソースへの悪意ある、または偶発的なアクセスを許してしまいます。

どのように

• 割り当てられた操作を完了するために必要な最小レベルのアクセス権（権限）のみをユーザーやサービスに付与します。この権限は、操作の完了に必要な最小限の時間だけ付与しなければなりません。
• アプリケーションアクセスに管理者アカウントを使用しない
• 機密データには別アカウントを使用する

例

• サービスプロセスは、必要な権限セットだけを持つ独自のユーザーで実行する
• 更新が不要な場合は読み取り専用権限を付与する
• 更新が必要な場合は、対象リソースのみにスコープを限定する

リンク

• https://owasp.org/www-community/Access_Control#principle-of-least-privilege
• https://csrc.nist.gov/glossary/term/least_privilege
• https://handbook.gitlab.com/handbook/security/security-and-technology-policies/access-management-policy/

なぜ

攻撃が成功した場合のブラスト半径（影響範囲）を制限します: システムの一部が侵害されても、システム全体が侵害されないようにします。

攻撃の魅力を低下させます。

どのように

• 責任と権限を区分けする
• 職務分離: 単一タスクの完了が 2 つ以上の条件に依存するようにする
• たとえ機密情報がフィルタリングされていても、設定などの非機密データと一緒に機密情報を保存しない

例

• git コミットの読み取りのみを必要とするシステム/サービスは、ユーザーデータにアクセスできるべきではない
• GitLab チームメンバーは課金データやその他の赤データに分類されたものへのアクセス権を持たない

リンク

• OWASP Access Control Models
• https://en.wikipedia.org/wiki/Compartmentalization_%28information_security%29

なぜ

• セキュリティ問題の多くは、通信経路に悪意ある中間者を挿入することによって引き起こされます

どのように

• 未知のエンティティは信頼されていないと仮定する
• 信頼を確立するための明確なプロセスを持つ
• 接続している人や物が誰/何であるかを検証する
• 必ず何らかの認証（証明書、パスワードなど）を使用する
• ネットワーク制御
• サードパーティのコードを動的にロードしない

例

• インターネットに公開されていないからといって、サービスがセキュアであるとは見なせません。SSRF は、攻撃者がそれらに自由にアクセスすることを許す可能性があります。
• ユーザーを認証する最善の方法は、この一般的なセキュリティ原則を適用することです: あなたが知っている何か（例: パスワード）と、あなたが所有する何か（例: 証明書）を提供する。これは MFA で適用しているもので、たとえばあなたが知っているパスワードと、アプリケーションによって生成される TOTP を提供することで実現します。
• 実行時にサードパーティのライブラリやスクリプトをダウンロードすると、キャッシュポイズニング、XSS など、多くのセキュリティ問題につながる可能性があります。外部アセットの完全性をチェックしないと、悪意のあるアクターがファイルを改ざんできてしまいます。たとえば、この BGP ハイジャック の事例を参照してください

リンク

• GitLab における Zero Trust

なぜ

• シンプルなソリューションはデプロイ、保守、セキュリティ確保が容易
• 私たちのイテレーションと効率性のバリューに整合する
• セキュリティには設計の理解が必要
• 複雑性は指数関数的に増加する
• ソフトウェアの攻撃可能性または攻撃面が削減される

どのように

• 複雑な障害モード、暗黙の動作、不要な機能を避ける
• よく知られた、テスト済み、実証済みのコンポーネントを使用する
• オーバーエンジニアリングを避け、代わりに MVC を目指す

例

• GitLab に新しいサーバーを導入することは、Omnibus ビルド、Helm チャート、リファレンスアーキテクチャ、ドキュメントなどを更新することを意味します。これは、完璧にフィットしそうに見えるコンポーネントを追加することの利点と慎重にバランスを取るべきものです。

リンク

• Keep it simple, stupid
• Complexity and exponential change

なぜ

• 活動の記録を提供する
• 不正行為を抑止する
• 過去を再構成するためのログを提供する
• 監視ポイントを提供する

どのように

• すべてのセキュリティ上重要なイベントを改ざん耐性のあるストアに記録する
• すべての機密性の高いイベントについて通知を提供する

例

• AWS で GuardDuty を有効化する、または GCP で Cloud Audit Logs を有効化して、活動を記録し悪意ある意図を検出する。
• SIEM（gitlab.com の場合は Devo）を活用してログを収集、正規化、分析する。
• 以下のような場合にユーザーに通知を提供する:
  • アカウントへの変更
  • 新しいキーが生成、またはアカウントに追加された
• 異常な活動についてセキュリティイベント（Slack 通知など）を生成する:
  • シグナルがしきい値を超過（レート制限が作動）
  • コンポーネント署名が一致しない
  • 機密性の高いリソースへの不正アクセス

リンク

なぜ

• デフォルトのパスワード、ポート、ルールは「開いたドア」である
• 障害状態や再起動状態はしばしばデフォルトで「安全でない」状態になる

どのように

• セキュリティ上機密性の高いパラメーターの変更を強制する
• 安全でありながら回復可能であるよう、障害について十分に考える
• サブジェクトがオブジェクトへの明示的なアクセス権を与えられない限り、そのオブジェクトへのアクセスは拒否されるべき。これは Fail Safe Defaults と呼ばれます。

例

• 無効/期限切れの TLS 証明書を信頼しない
• Grafana のような一部のコンポーネントはデフォルトの admin/admin ユーザー/パスワードで提供される。
• 上記に関連して、一部のコンポーネントは、サービスが到達不能な状態など特定の条件下で、デフォルト認証情報による平文のユーザー/パスワード認証にフォールバックすることがある。
• 一部のフレームワークは、リソースに接続できない場合、ホスト名やパスなど共有すべきでない詳細情報を含むエラーページをレンダリングする傾向がある。

リンク

• https://owasp.org/www-community/Fail_securely

なぜ

• 隠すことは難しく、誰かが偶然または意図的に見つけてしまう
• 私たちは非常に透明性の高い会社であり、実装の詳細を共有することが多く、ときおり機密情報を漏らしてしまう可能性がある。
• オフボーディングされた従業員は機密情報の知識を持って去ります。トークンはローテーションできますが、その知識が漏洩しないことを保証することはできません

どのように

• 完全な知識を持つ攻撃者を想定する

例

• 偵察により、攻撃者は公にドキュメント化されていないサーバーを見つけることができます。これらのサーバーは脆弱なコンポーネントを公開し、東西方向への侵害につながる可能性があります。
• 管理者セクションへのパスを変更しても、攻撃者が最終的にそれを見つけることを防ぐことはできません。

リンク

• https://securitytrails.com/blog/security-through-obscurity

なぜ

• システムは攻撃される、侵害は発生する、ミスは起きる
• ブラスト半径を最小化する: 1 つのコンポーネントが侵害されても、システム全体を侵害してはならない
• SSRF を防ぐ

どのように

• セキュリティの単一ポイント/レイヤーに依存しない:
  • すべてのレベルを保護する
  • 1 つのレベルでの障害が伝播するのを止める
• 保存時および転送時のデータを暗号化する（GitLab の暗号化ポリシーに従う）
• 脆弱性スキャナーを使用する
• 不要なポートを閉じ、未使用機能を無効化する

例

• リソースは UI からアクセスする場合は十分に保護されているが、API を通じてはより露出される可能性がある。
• ブルートフォース攻撃を回避するために、試行回数が多すぎる場合にアカウントをロックする。
• OS 実行は、実行がアプリケーションの外部で発生するため、すべてのアプリケーションセキュリティレイヤーをバイパスすることにつながる可能性がある。
• 不要な開放ポートと有効化された機能は、認証バイパスやその他の脆弱性につながる可能性がある。これらはアプリケーションの露出を増加させる。

リンク

• https://en.wikipedia.org/wiki/Defense_in_depth_(computing)
• GitLab における Zero Trust

なぜ

• セキュリティ技術を作ることは難しく、脆弱性を回避することも難しい
• 新しいセキュリティ技術をセキュアで成熟したものにするには何年もかかる
• それらは（ある意味）完璧であることが期待される

どのように

• [独自の暗号を作らないこと]
• よく知られた実証済みのコンポーネントを使用する
• 疑わしい場合は、常に適切な SME を関与させる

例

• SSO をスクラッチから実装しないこと

リンク

• レインボーテーブルは暗号化ハッシュ関数の出力をキャッシュするために使用され、パスワードハッシュをクラッキングするのに使用できる。
• bcrypt のデフォルトコストファクターの危険性: 有名な暗号ライブラリを使用していても、その設定が脆弱性につながる可能性がある。

なぜ

• システムは最も弱いリンクと同じ強度しかない
• 時間の経過とともに新しい脆弱性が発見され、コンポーネントが突然新しい弱いリンクになる可能性がある

どのように

• システムを脅威モデリングし、繰り返し、イテレーションする。
• 中央のコンポーネントを特定する:
  • 他より多くの権限を共有している
  • 他のコンポーネントへの接続がより多い
  • エントリーポイントである（ログインモジュール、API など）
• 依存関係スキャンを実行する
• 弱い暗号やアルゴリズムを避ける
• ときには人間（ユーザー）を最も弱いリンクと考える。フィッシングが今も広く使用されているのには理由がある

例

• 一部のリソースは UI で非常に十分に保護されており、認可されていないユーザーには決して公開されません。しかし、API がセキュリティ制御を正しく実装していない場合、これらのリソースが機密データをフィルタリングせずに生のモデルとして渡される可能性があります。
• 転送時には暗号化されているが、保存時には暗号化されていないデータ。
• 最も弱いリンクはユーザーである場合もあります。強力なパスワードと MFA を強制しないことは機密データの露出につながる可能性がありますが、ユーザーは気づかずに有害な行動を取ることもあります。
• OS（システム）コマンドは、アプリケーションのセキュリティ制御の大部分、あるいはすべてをバイパスすることにつながることが多いです。これは RCE の一般的なベクターであり、可能な限り避けるべきです。

リンク

• ExifTool でメタデータを削除する際の RCE
• Log4Shell: 人気の Java ロギングパッケージ log4j 2 で発見された RCE 0-day エクスプロイト