安全でないシステム構成とは？

安全でないシステム構成は、OWASPのCI/CDセキュリティリスクのトップ10です。CI/CDシステムが最適でない、またはデフォルトの構成でデプロイした場合に発生します。不要なオープンポート、デフォルトの認証情報、パッチが適用されていないシステム、分離が不十分なネットワーク、無効化されたセキュリティ機能などです。これらの脆弱性は、システムを不正アクセスにさらし、マルウェアの伝播やデプロイメントプロセスへの悪意のあるコードインジェクションの可能性を増大させ、最終的にデータ漏洩や業務妨害につながる可能性があります。安全でない設定は、正規のCI/CDプロセスの悪用にもつながり、攻撃者がワークフローを操作して本番環境にアクセスすることを可能にします。

CICD-SEC-7：安全でないシステム構成の説明

安全でないシステム構成は、重大なセキュリティリスクとなります。これは、ソースコード管理（SCM）、CI システム、成果物リポジトリなど、パイプライン全体にわたるさまざまなシステムのセキュリティ設定、構成、およびハードニングの欠陥から発生します。このような脆弱性は、環境内で手を広げようとする攻撃者にとって、しばしば格好の標的となります。

様々なベンダーの複数のシステムがCI/CD環境を構成しています。 CI/CD セキュリティを強化するためには、パイプラインを流れるコードや成果物だけでなく、個々のシステムのスタンスや回復力にも集中することが不可欠です。

データの保存と処理システムと同様に、CI/CDシステムには、アプリケーション、ネットワーク、およびインフラストラクチャレベルで多数のセキュリティ設定と構成が含まれます。これらの設定は、CI/CD 環境のセキュリティ態勢と潜在的な侵害に対する感受性を決定する上で重要な役割を果たします。

攻撃者はCI/CDの脆弱性や設定ミスを悪用しようとします。想定される硬化の欠陥は以下の通り：

• 古いバージョンを実行しているシステム
• ネットワークアクセス制御が過度に寛容なシステム
• 基盤となるOSに管理者権限を持つセルフホストシステム
• クレデンシャルの衛生状態の悪さ

システム構成の定義

システム・コンフィギュレーションとは、システムやサービスを設定し、それらがどのように相互作用するかを定義し、それらの動作を制御するルールを確立するプロセスを指します。これには、ハードウェアのセットアップ、ソフトウェアのインストールと設定、ネットワーク接続の確立などが含まれます。設定プロセスは、システムの機能、パフォーマンス、およびセキュリティに大きな影響を与える可能性があるため、正しく設定し、最適な状態を維持することが極めて重要です。

安全なシステム構成の構成要素

セキュアな構成には、システムパラメータを正しく設定し、アクセス制御を管理し、 CI/CDパイプラインを支えるシステムのセキュリティ対策を実装することが含まれます。このような構成は、不正アクセスのリスクを軽減し、開発環境の基幹となるシステムの脆弱性の悪用を防止します。

CI/CD環境における複雑さは、システム構成が個々のシステムにとどまらず、パイプラインで使用されるツール、サービス、プラットフォーム間の相互接続にまで及ぶという点から生じています。当然のことながら、効果的で安全なシステム構成の主要な要素は、厳密な構成管理です。

CICD-SEC-7の仕組み

安全でないシステム構成の根本的な原因は、多くの場合、人為的なミス、適切な手順の欠如、セキュリティ要件の不十分な理解にあります。デフォルトの設定を変更しない、過剰なパーミッションを許可する、システムのアップデートやパッチを怠るなど、単純なことが原因で発生する可能性があります。

仮定の状況

攻撃者は、人工知能を専門とする技術系企業である標的のネットワークをスキャンし、デフォルト設定で設定されたJenkinsサーバーが公開されていることを発見します。すぐに利用可能なツールとAPIコールを使用して、Jenkinsサーバーのメタデータをマイニングし、基盤となるシステムに関する潜在的な情報を探ります。プラグイン、ジョブ、システム設定など、さまざまな情報が画面にあふれ出します。その中で、ひときわ目を引く情報があります。AWSのキー。AWS上のアプリケーションのデプロイにJenkinsが使用していましたが、セキュリティが十分ではありませんでした。このキーは管理者アカウント用のもので、企業のAWS環境に無制限にアクセスできる可能性があります。

このキーを使って企業のAWSインフラに侵入し、攻撃者は組織のシステムの中枢に侵入します。彼らは、独自のAIモデルを格納するS3バケットを見つけ、盗んだAWSキーから管理者レベルのアクセス権を使用して、モデルを迅速にダウンロードし、アラームをトリガせずに終了します。

その後、攻撃者はこのシステムをさらに悪用することを決定します。JenkinsサーバーがGitHubリポジトリへの書き込み権限を持っていることを認識し、アプリケーションへのバックドアを作成する悪意のあるコードスニペットをメインアプリケーションのソースコードに仕込みます。次のデプロイメントサイクルでは、会社は無意識のうちにアプリケーションを本番環境にプッシュします。永続的なバックドアで武装した攻撃者は、データを盗み出し、システム制御を操作し、さらにマルウェアを仕込むことができます。

CI/CDにおけるセキュアなシステム構成の重要性

エンジニアリング環境のどの時点でも設定ミスがあれば、パイプライン全体が潜在的な脅威にさらされる可能性があります。設定ミスを利用した攻撃者は、CI/CDシステムに不正アクセスする可能性があります。攻撃者は正規のCI/CDフローを操作し、機密トークンを取得し、本番環境にアクセスする可能性があります。シナリオによっては、コンフィギュレーションの欠陥によって、攻撃者が環境内やCI/CDシステムのコンテキスト外を横方向に移動できるようになることがあります。

安全でないシステム構成に関連するリスク

安全でないシステム構成に関連するリスクを理解している DevOps チームは、脆弱性の少ないシステムを設計し、設計したシステムのセキュリティに責任を持ち、リスクが発生した場合にリスクを軽減することができます。

ケーススタディ1：PHP、セキュリティインシデントとユーザーデータベース流出の可能性を受けてGitHubに移行

2021年4月、PHPコミュニティはgit.php.netに関わるセキュリティインシデントに直面しました。当初はサーバーの侵害が疑われましたが、調査の結果、悪意のあるコミットがHTTPSとパスワードベースの認証を使用して行われ、Gitoliteインフラストラクチャをバイパスしていたことが判明しました。master.php.netのユーザーデータベースが流出した可能性があり、main.php.netへのシステム移行と全php.netユーザーのパスワードリセットが必要です。Git.php.netとsvn.php.netが読み取り専用になり、PHPの主要なリポジトリがGitHubに移されたことで、セキュリティが強化され、開発ワークフローが合理化されました。

ケーススタディ2：Webmin、悪意のあるコード挿入事件を受けてセキュリティ対策を総点検

2019年8月、Webベースのシステム設定ツールであるWebminは、そのソースコードに悪意のあるコードが挿入され、セキュリティ侵害を受けました。この違反は偶発的なバグではなく、リモートからのコマンド実行を許してしまうものでした。悪意のあるコードは、侵害された開発ビルドサーバー経由で導入されました。発見後、Webmin はビルドプロセスをアップデートし、GitHub からチェックインされたコードのみを使用するようにし、アクセス可能なすべてのシークレットをローテーションし、過去 1 年間のすべての GitHub コミットに同様の脆弱性がないか監査しました。

ケーススタディ3：北米日産、Gitサーバーの設定ミスでソースコードがネット上に流出

北米日産のモバイルアプリや社内ツールのソースコードが、Gitサーバーの設定ミスによりネット上に流出するという重大なセキュリティ上の問題が発生しました。このサーバーは、デフォルトのユーザー名とパスワードが「admin/admin」のまま放置されており、スイス在住のソフトウェア・エンジニア、ティリー・コットマンによって発見されました。リポジトリには、さまざまな日産アプリ、診断ツール、ディーラーポータル、マーケティングツールなどのコードが入っていました。日産自動車は、このインシデントを確認し、影響を受けたシステムを保護し、個人データへのアクセスはなかったと主張しました。

ケーススタディ4ニューヨーク州IT局、内部コードリポジトリをオンライン公開

ニューヨーク州のIT部門が使用していた内部コードリポジトリが、不注意にもオンラインで公開され、誰でもアクセスできる状態になっていました。サイバーセキュリティ企業SpiderSilkによって発見されたGitLabサーバーには、州政府システムの秘密の鍵とパスワードが含まれたプロジェクトがありました。このサーバーは、誰でもユーザーアカウントを作成してログインできるように設定されていました。サーバーは3月18日に初めてオンラインであることが検知され、暴露が報告された後にオフラインにされました。このサーバーは、ベンダーが設置したテストボックスであり、その後廃止されたと報告されています。

CI/CDにおける安全でないシステム構成の防止

設定ミスは攻撃者の侵入口となり、重大なセキュリティ侵害につながりますが、安全なシステム設定は多くの開発プロセスで見過ごされています。 OWASPのCI/CDセキュリティリスク・トップ10の 著者によるインサイダーの推奨は、あなたのシステムを良好な状態にすることができます：

• 使用中のシステムとバージョンのインベントリを管理し、各システムを指定された所有者にマッピングします。これらのコンポーネントに既知の脆弱性がないか、定期的にチェックしてください。セキュリティパッチが利用可能になったら、脆弱なコンポーネントを更新してください。脆弱なコンポーネントに対応するパッチがない場合は、そのコンポーネントまたはシステムの削除を検討してください。あるいは、システムのアクセスや機密操作の実行を制限することで、脆弱性が悪用された場合の潜在的な影響を最小限に抑えます。
• システムへのネットワークアクセスが 最小限のアクセス権の原則に沿ったものであること。
• すべてのシステム構成を定期的に見直すプロセスを設定します。システムのセキュリティ態勢に影響を与える可能性のある設定に重点を置いてレビューしてください。最適化を図ります。
• 最小特権の原則に基づいて、パイプライン実行ノードに権限を付与します。この文脈でよくある設定ミスは、エンジニアに実行ノードのデバッグ権限を与えることです。多くの組織ではこれを許可していますが、デバッグモードで実行ノードにアクセスできるユーザーであれば、メモリにロードされている間にすべての秘密を暴露してしまう可能性があることを考慮することが重要です。また、ノードの ID を使用し、この権限を持つエンジニアに効果的に昇格した権限を付与することもできます。

システム構成セキュリティの業界標準

重大な業界標準は、システム構成セキュリティのベストプラクティスを概説しています。Center for Internet Security (CIS)は、安全な設定のための包括的なベンチマークを提供し、National Institute of Standards and Technology (NIST)も、セキュリティのためのシステム設定のガイドラインを公表しています。

秘密の暗号化

パスワード、APIキー、データベースの認証情報などの秘密は、RESTおよび転送時に暗号化する必要があります。 コードやコンフィギュレーション・ファイルには、決して秘密を書かないでください。HashiCorp VaultやAWS Secrets Managerのようなシークレット管理ツールを使用してください。これらのツールは秘密を暗号化し、アクセスを制御することで、組織の認証情報が悪人の手に渡るのを防ぎます。

システムのログと監視

セキュアなシステム構成を維持するために重要なことは、明確なポリシーを確立し、コンプライアンスを定期的に監視することです。不審な行動を検知し、セキュリティ・インシデントに迅速に対応できるよう、すべての行動を記録することが重要です。また、異常なトラフィックパターンやログインの失敗など、攻撃の兆候がないかシステムを監視する必要があります。

脆弱性へのパッチ適用

包括的な脆弱性の特定とパッチ適用システムを確実に導入してください。脆弱性を体系的に特定し、改善の優先順位を決定します。脆弱性にパッチを当てられない場合は、管理者権限を削除するなどの代替手段を用いてください。システムを最新の状態に保つということは、サーバー、アプリケーション、CI/CDツールに定期的にパッチやアップデートを適用するということです。

不要なアカウントと権限の削除

不要なアカウント（孤児アカウントや未使用アカウントなど）を削除することで、最小権限を強制します。これは、アタックサーフェスを減らすための最も強力なセキュリティプラクティスの1つです。ユーザー、プロセス、サービスを含むシステムの各コンポーネントが、その機能を実行するために必要な最小限の権限しか持たないようにします。そうすることで、部品が破損した場合の損害を最小限に抑えることができます。

ネットワークの障害物

ネットワークをより小さく、孤立したセグメントに分割することで、攻撃者がネットワークにアクセスした場合の横方向の動きを制限することができます。ファイアウォールとアクセス制御リスト（ACL）を使用して、セグメント間のトラフィックを制御します。トラフィックを暗号化し、未使用または不要なオープンネットワークポートをブロックし、不要なプロトコルやサービスを無効化または削除します。ファイアウォールのルールを定期的に監査してください。

ビルドサーバのセキュリティ

ビルド・サーバーはコードのコンパイルやパッケージングを行うため、攻撃者にとって格好の標的となります。ビルド・サーバが、最新のセキュリティ・パッチと強力なパスワードで適切に保護されていることを確認してください。そして、ビルド環境の安全を確保するということは、本番環境から隔離するということであることを忘れないでください。

既存システムの監査

定期的な監査とレビューは、システム構成が長期にわたって安全であり続けることを保証するのに役立ちます。既存技術の包括的な監査を実施します。侵入テスト、脆弱性スキャン、構成管理、その他のセキュリティ監査ツールを使用して、システムの欠陥を発見し、修正の優先順位を決定します。NIST、Microsoft、CIS、DISAなどの業界標準を使用したリソースに対するシステム評価の実施。

安全なシステム構成に役立つツールの使用

システム・コンフィギュレーションを管理し、保護するためのツールは数多く存在します。Ansible、Chef、Puppetなどの構成管理ツールは、自動構成と環境間での一貫したアプリケーションを可能にします。クラウドベースのシステムの場合、AWS Config、Azure Policy、Google Cloud Security Command Centerなどのクラウドネイティブサービスが、安全な設定の維持に役立ちます。

安全でないシステム構成に関するFAQ