犯罪者に家の鍵を渡すのは決して良い考えではない。しかし、現代のソフトウェアを開発するほとんどの組織では、しばしばそのようなことが起こっている。
機密情報漏洩に関する最初の記事となる本稿では、なぜこのような事態が頻繁に発生するのか、その影響は何か、そして問題の予防や軽減、機密情報漏洩事件への対処のためにどのような対策を講じるべきかを分析します。
やばい！クラウドアクセスキーを公開リポジトリにプッシュしちゃった。
ハードコードされた秘密 ソースコードやDevOpsツールの構成ファイル内の秘密が、悪意のある者の手に渡る可能性がある。 commit公開されているソースリポジトリに機密情報が保存されている場合、確実に破滅します。しかし、プライベートリポジトリであっても安全とは言えません。機密情報は、アプリケーションのバイナリ、ログ、または盗まれたソースコードを通じて漏洩する可能性があるからです。
振り返ってみると、それは不穏なことだ 些細な見落としが、どれほど頻繁に深刻なセキュリティ侵害につながってきたか。 「グーグルで検索してください」AWSキーの漏洩"、"GitHubアクセストークンの漏洩「、など。これらの例を、特定のベンダーへの隠れた推奨事項として受け取らないでください。独自のものを使用してください！」
例えば、（悪名高い） Codecov攻撃 2021 年 4 月に発生した脆弱性は、Codecov の Docker イメージに、攻撃者が Codecov のプライベート Git リポジトリにアクセスし、Codecov の bash アップローダー スクリプトに収集環境変数と Git リポジトリ URL の 1 行を追加できる Git 認証情報が含まれていたために発生しました。
攻撃における報酬の一部は、追加システムへのアクセス権を得るための秘密情報であり、多くの攻撃は認証情報、暗号鍵、トークンの流出に多大な投資を行っていることを忘れてはならない。
問題があることです。 ハードコードされた秘密はよくあることだ2022年3月、Lapsus$ APT 189GBが流出 サムスンのソースコードやその他の機密ファイルの一部。分析の結果、いくつかの 6,600個のハードコードされた秘密情報内部システムでは90%、GitHub、AWS、Googleなどの外部サービスやツールでは10%が機密情報として扱われています。これらの機密情報には、AWS、Twilio、GoogleのAPIキー、データベース接続文字列、その他の機密情報が含まれます。これは、ほとんどのコードベースにおける最先端のセキュリティ対策です。
機密情報の漏洩は、サプライチェーン攻撃への最も容易な経路である。
パッケージの依存関係は、サプライチェーン攻撃の標的として最も頻繁に見られるものの、唯一の標的ではありません。攻撃者は、被害者のソフトウェアにインストールされる新しいパッケージを作成する可能性があります（ しゃがんだ （およびその他の技術）だが、通常はソフトウェアリポジトリのソースコードに変更を加えることによって既存のパッケージに感染させようとする（SCMGitHub、GitLab、BitBucketなどのサービスに悪意のあるバージョンを追加したり、NPM、PyPI、RubyGems、Maven Centralなどの公開レジストリに悪意のあるバージョンを追加したりすることによって行われます。
しかし、複雑な依存関係グラフに隠された悪意のあるコードや悪意のある依存関係を注入するには login ユーザー名/パスワード、トークン、アクセスキーなどの認証情報（これらを「キー（略して）ターゲットソースリポジトリまたはパブリックレジストリをそれぞれ指します。
悪者は時々鍵を 社会工学を選択します。 攻撃 event-stream 人気のある NPM パッケージは良い例を示しています。しかし、漏洩した login 認証情報またはアクセスキーは、ソフトウェアサプライチェーン攻撃において最も頻繁に用いられる攻撃手法である。
ソースリポジトリとパッケージレジストリは、ソフトウェアビルドにおいて不可欠な2つのシステムである。 pipelineしかし、DevOpsには多くのツールがあります。 CI/CD システム、テスト実行ツール、構成・プロビジョニング自動化ツール、デプロイ・リリースツールなど、これらはすべてソフトウェアに悪意のあるコードを注入するために悪用される可能性があります。これらのツールの有効なキーが漏洩すると、直接的に悲惨な事態を招きます。パブリッククラウドのリソースを完全に制御できるルートアクセスキーが漏洩することを想像してみてください…。
いつもの推奨事項
ここで新しいことを言うつもりはありません。皆さんもご存知でしょう。しかし、行動を起こしましょう！ボットが定期的にすべての公開情報をスキャンしていることを忘れないでください。 SCM リポジトリ。いくつかおすすめを紹介します（順不同）。
- ITセキュリティ管理の責任を負っている場合、 秘密情報の取り扱い方法を定義する セキュリティポリシーに明記する必要があります。しかし、ポリシーは実施されてこそ意味を持ちます。組織全体で機密情報の取り扱いに関するガイドラインが確実に実施されるようにし、DevOpsチームだけでなくソフトウェアサプライヤーも対象に含め、組織のインシデント対応計画に機密情報漏洩事故への対応策が含まれていることを確認してください。
- 実装と施行 マルチファクタ認証 （MFA、2FA、または略語は何でも構いません）。セキュリティを妥協する必要はありません。USBセキュリティキーは、数ドルの費用に見合う価値があります。何千もの認証情報をgit pushして（簡単です）、酔っ払って、自分と関連付けられる何かと一緒にキーをバーに置き忘れる（特に禁酒家なら、その可能性は少し低くなります）というリスクを負うだけです。
- 強力で保存されていないパスワードを使用するパスワードマネージャーを使用してください。システム内の秘密情報を扱うには、 秘密の金庫. CI/CD システム、クラウドプロバイダー、 SCMsやその他のDevOpsツールはこのサービスを提供していますが、汎用的なシークレットボールトソリューションを選択することもできます。
- 好む 短命の トークンを長期有効のアクセスキーに置き換える。トークンは失効しやすく、悪意のある攻撃を受ける可能性も限定的である。
- 認証情報の再利用を制限する攻撃者は、標的システムから入手した認証情報を他のシステムで再利用する可能性があるため、パスワードマネージャーの使用が重要になります。パスワードマネージャーとシークレットボールトを使用すれば、認証情報の再利用は過去のものとなるはずです。
- 使用を制限し、監視する 管理人 パスワード。それらは特別な監視に値するほど強力な情報源です。
- 実施する 強力なハッシュ化と暗号化USB（暗号化）キー、パートナーや同僚との間で認証情報を送信するための厳格な手順などに戻る。
- 使用 シークレットスキャナー例えば、 pre-commit フック バージョン管理システムにおける情報漏洩を防ぐためのセキュリティゲートとして。 その前に ここではが重要です。あるいは、例えばチェックとして事後スキャンを使用して、漏洩した秘密を検出します。 pull request マージします。注：当社のXygeniプラットフォームには、両方の動作モードに対応したシークレットスキャナーが含まれています。
- 手動代替手段を使用する コードレビュー ハードコードされた秘密を探すにはコストが高く、後から作業する必要があります。commit （ただし、少なくともその秘密が外部の人間に知られる前に発見されることを願う）。しかし、レビューによって、秘密スキャナーをすり抜ける可能性のある、従来とは異なる秘密が発見されるかもしれない。
- 誤って避ける commit適切な方法で、シークレットを含む共通ファイルをバージョン管理に渡す 除外するパターン （`gitignore`テンプレートのように）次のようなファイルを考慮する
.env,.npmrc,.pypirc一時ファイル…確かにセキュリティの層が一つ増えたと言えるでしょう。 - そしてこの長いリストの最後は、クラウドプロバイダーが可能な限り鍵の漏洩スキャンを実行できるようにすることです。少なくとも、 かもしれません 漏洩が発生した際にはお知らせしますが、クラウドプロバイダーにとってセキュリティは必須です。 事後 秘密スキャンは、スキャンがどこでどのくらいの頻度で実行されるかについて透明性が低く、明示的な設定が必要な場合が多いが、他のすべての手段が失敗した場合の最後の手段であることは間違いない。
やばい！クラウドアクセスキーを公開リポジトリにプッシュした、2回目
それは誰にでも起こりうることだ。さあ、腕まくりをしよう！
漏洩した秘密鍵は直ちに更新／失効／無効化してください！アカウントに適切な多要素認証（MFA）が設定されていれば、リスクは大幅に低減されます。ウェブサイトの秘密鍵などでは、新しい秘密鍵用の新しい証明書を発行し、既存の証明書を失効させる必要があるため、対応がより困難になる場合がありますが、最新のツールを使えば、認証情報の更新やトークンの失効を迅速に行うことができます。
プロバイダーが推奨する手順が利用可能な場合は、それに従ってください。 この例ではAWSを使用しています.
漏洩の原因を特定する。漏洩の発生経緯を把握することは、情報開示、分析、封じ込め、および教訓の抽出といった活動にとって不可欠である。
次に、漏洩が発生したことを関係者に報告し、漏洩を食い止め、被害を軽減するために講じている措置を説明してください。漏洩した損害を元に戻す方法はありません。漏洩した分は取り返しがつきません。透明性を保ち、関係者に情報を提供することで、適切な対応を取ることができます。
次に、 フォレンジックを選択します。 露出ウィンドウ これは、情報漏洩が発生してから秘密鍵が無効になった時点までの時間です。この期間中、影響を受けたアカウントのログを確認し、異常なアクティビティがないか追跡する準備をしてください。影響を受けたアカウントを使用して生成されたアカウントとキーを削除してください。影響を受けたアカウントに管理者権限がある場合、修正ははるかに複雑になることに注意してください。
（バージョン管理の）履歴の書き換え 複雑です。全体主義国家でさえ、これを試みても無駄に終わります（ダジャレのつもりです）。また、おそらく関係ないかもしれませんが、公開リポジトリのハッカーやボットは、リポジトリをクローンしたり、既に金を抽出したりしている可能性があり、特に露出期間が十分に長い場合はその可能性が高くなります。
もしあなたが冒険好きで、ボットが漏洩した秘密を検出するのにどれくらい時間がかかるかを自分で確かめたいなら、次のようなトリップワイヤーがあります。 カナリアトークン 実験させてください。ボットはデフォルトをブラックリストに登録していることを覚えておいてください。 canarytokens.org ドメイン…
| さらに読むには、Kovacs, E. “流出したサムスンのソースコードから数千もの秘密鍵が発見される「セキュリティウィーク、2022年3月。ダイジャック、A.」数日前、秘密に関して小さな実験を行いました commit公開されているGitリポジトリに編集されました…「。ツイート スレッド、2020 年 11 月。Rzepa、P.」AWSアクセスキーがGitHubリポジトリに流出、Amazonの対応に若干の改善が見られる「. Medium、2020年11月。」 |
