CICD-SEC-2 不十分な ID およびアクセス管理 (Inadequate Identity and Access Management)

定義

不十分な ID およびアクセス管理のリスクはソース管理からデプロイメントまでエンジニアリングエコシステムのさまざまなシステムに広がる膨大な量の ID の管理の難しさに起因します。管理不十分な ID (人間のアカウントとプログラマティックアカウントの両方) が存在すると、侵害の可能性と損害の程度が増大します。

解説

ソフトウェア配信プロセスはコードとアーティファクトを開発から本番環境に移すことを目的として互いに接続された複数のシステムで構成されています。各システムは複数のアクセスと統合の手法 (ユーザー名とパスワード、個人アクセストークン、マーケットプレイスアプリケーション、oauth アプリケーション、プラグイン、SSH キー) を提供します。さまざまなタイプのアカウントとアクセスの手法が独自のプロビジョニング手法、セキュリティポリシーのセット、認可モデルを潜在的に持つ可能性があります。この複雑さにより ID のライフサイクル全体を通じてさまざまな ID を管理し、最小権限の原則に沿ったパーミッションを確保するという課題を生じます。

さらに、典型的な環境では、SCM や CI の平均的なユーザーアカウントは非常に寛容です。これらのシステムは従来セキュリティチームにとって主要な重点領域ではなかったためです。これらの ID は主にコードやインフラストラクチャに大きな変更を加えることができる柔軟性を必要とするエンジニアによって使用されます。

CI/CD エコシステム内の ID およびアクセス管理に関する主な懸念事項と課題には以下があります。

  • 過度に寛容な ID - アプリケーションと人間の両方のアカウントについて最小権限の原則を維持すること。たとえば、SCM の場合、人間とアプリケーションの各 ID に必要なパーミッションのみが付与され、アクセスする必要がある実際のリポジトリに対してのみ付与されていることを確認するのは、簡単ではありません。

  • 古い ID - アクティブではなくなったりアクセスする必要がなくなった従業員やシステムだが、すべての CI/CD システムに対してそれらの人間のアカウントやプログラマティックアカウントをプロビジョニング解除されていないこと。

  • ローカル ID - 一元管理型 IDP と連携したアクセス権を持たないシステムでは、問題となるシステム内でローカルに管理される ID を作成します。ローカルアカウントは一貫したセキュリティポリシー (パスワードポリシー、ロックアウトポリシー、MFA など) を適用したり、(従業員が退職した場合などに) すべてのシステムで適切にアクセス権をプロビジョニング解除する際に課題が生じます。

  • 外部 ID -

    • 組織が所有や管理をしていないドメインの電子メールアドレスで登録された従業員 - このシナリオでは、これらのアカウントのセキュリティは割り当てられた外部アカウントのセキュリティに大きく依存します。これらのアカウントは組織が管理していないため、必ずしも組織のセキュリティポリシーに準拠しているとは限りません。

    • 外部協力者 - 外部協力者にシステムのアクセスを許可すると、システムのセキュリティレベルは組織の管理外にある外部協力者の作業環境のレベルによりもたらされます。

  • 自己登録 ID - 自己登録が許可されているシステムでは、有効なドメインアドレスが自己登録と CI/CD システムへのアクセスの唯一の前提条件であることがよくあります。システムに対して「なし」以外のデフォルトやベースのパーミッションセットを使用すると、潜在的な攻撃対象領域が著しく拡大します。

  • 共有 ID - 人間のユーザー間、アプリケーション間、人間とアプリケーションの両方で共有される ID は認証情報の影響範囲を増やすだけでなく、潜在的調査の際の説明責任に関連する課題が生じます。

影響

CI/CD エコシステムには、人間とプログラマチックの両方で、数百 (時には数千) の ID が存在しています。強力な ID およびアクセス管理プラクティスの欠如と過度に寛容なアカウントの一般的な使用と相まって、いずれかのシステムのより近いいずれかのアカウントを侵害すると、その環境に強力な機能を付与でき、本番環境へ移ることが可能な状態に至ります。

推奨事項

  • エンジニアリングエコシステム内のすべてのシステムにおいて、すべての ID の継続的な分析とマッピングを実施します。各 ID に対して、ID プロバイダ、付与されるパーミッションのレベル、実際に使用されているパーミッションのレベルをマップします。プログラマチックアクセスのすべてのメソッドがその分析に含まれていることを確認します。

  • 環境内のさまざまなシステムにおける各 ID の継続的な作業に必要でないパーミッションを削除します。

  • 古いアカウントの無効化・削除の許容期間を決定し、所定の非アクティブ期間を過ぎた ID を無効化・削除します。

  • ローカルユーザーアカウントの作成を避けます。代わりに、一元管理された組織コンポーネント (IdP) を使用して ID を作成および管理します。ローカルユーザーアカウントを使用している場合には、アクセスを必要としないアカウントを無効化または削除し、すべての既存アカウントに関するセキュリティポリシーが組織のポリシーと一致していることを確認します。

  • すべての外部協力者を継続的にマップし、その ID が最小権限の原則に沿っていることを確認します。可能な限り、人間のアカウントとプログラマティックアカウントの両方に対して、あらかじめ有効期限を設定してパーミッションを付与し、作業が完了したらそのアカウントを無効にします。

  • SCM、CI、またはその他の CI/CD プラットフォームに対して、従業員が個人の電子メールアドレスや組織が所有や管理をしていないドメインに属するアドレスを使用できないようにします。さまざまなシステムにわたって非ドメインアドレスを継続的に監視し、準拠していないユーザーを削除します。

  • ユーザーにシステムへの自己登録を許可することは控え、必要に応じてパーミッションを付与します。

  • システムの基本パーミッションをすべてのユーザーやユーザーアカウントが自動的に割り当てられる大きなグループに付与することは控えます。

  • 共有アカウントの使用を避けます。特定のコンテキストごとに専用のアカウントを作成し、問題となるコンテキストに対して必要なパーミッションのセットを正確に付与します。

参考情報

  1. Stack Overflow TeamCity ビルドサーバーの侵害 - 新しく登録されたアカウントにはシステムへのアクセス時に管理者権限が割り当てられていたため、攻撃者は環境内で権限を昇格できました。

    https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our-may-2019-security-incident/

  2. Mercedes Benz のソースコード流出はインターネットに公開された自己管理型の GitLab サーバーが自己登録でアクセスできたことが原因でした。

    https://www.zdnet.com/article/mercedes-benz-onboard-logic-unit-olu-source-code-leaks-online/

  3. New York 州政府の自己管理型 GitLab がインターネットに公開され、機密情報が保存されているシステムに誰でも自己登録してログインできました。

    https://techcrunch.com/2021/06/24/an-internal-code-repo-used-by-new-york-states-it-office-was-exposed-online/

  4. プロジェクト保守者の GitHub アカウントパスワードが侵害され、Gentoo Linux ディストリビューションのソースコードにマルウェアが追加されました。

    https://wiki.gentoo.org/wiki/Project:Infrastructure/Incident_Reports/2018-06-28_Github

Last updated