Skip to main content

In this article

DevSecOpsテクノロジー

著者
Headshot of Jamie Smith

Jamie Smith

0 分で読めます

テクノロジーは、DevSecOpsプロセスを適切に実行するための力となります。DevSecOpsやCI/CDと聞いて、多くの人がまず思い浮かべるのはツールでしょう。さまざまな開発、セキュリティ、運用プロセスを統合し、自動化する能力は、DevSecOpsを成功させるうえで中核となります。以下では、組織がエンタープライズ全体でDevSecOpsの手法を成功裏に導入するにあたり、検討すべきテクノロジーを紹介します。

ソースコードリポジトリ

ソースコードリポジトリは、世界中のほぼすべての開発環境の中核を担っています。DevSecOpsのアプローチを導入する際、リポジトリはパイプライン内のほかの多くのテクノロジーが連携する重要なテクノロジーです。組織がDevSecOpsパラダイムの導入準備を評価する際には、リポジトリがほかの重要なテクノロジーと連携できるかどうかを考慮する必要があります。

アプリケーション環境のさまざまな要素がコードで定義されるようになるにつれ、リポジトリのセキュリティが極めて重要になっています。ユーザーアクセスやリポジトリ設定などに関するベストプラクティスを実施する必要があります。許可されていない相手や不要な相手にリポジトリが公開されると、重大なリスクにつながる可能性があります。 

テクノロジー特集：Bitbucketリポジトリのベストプラクティス

DevSecOpsを導入する組織で特に広く利用されているリポジトリの1つがBitbucketです。使いやすいWebベースのインターフェイスと幅広いテクノロジーとの連携により、DevSecOpsに求められる自動化やオーケストレーションに最適です。しかし、人気が高まる一方で、リポジトリの安全でない設定や使い方を原因とするセキュリティ脆弱性も増えています。こうした問題を防ぐため、次のベストプラクティスを実践しましょう。

  1. Bitbucketに認証情報をコードや設定として保存しない
    Bitbucketに保存するリポジトリでは、常にシークレット管理のベストプラクティスに従いましょう。git-secretsの活用、シークレットの定期監査、信頼できるシークレットマネージャーの利用などが挙げられます。

  2. 機密データを削除する
    機密データがリポジトリに含まれてしまった場合は、公開されたすべてのトークンとパスワードを無効化し、情報を削除してGitの履歴を消去したうえで、漏えいした個人情報の影響を評価してください。

  3. アクセスを厳格に管理する
    リポジトリのセキュリティ侵害は、人為的なミスが原因であることが少なくありません。このリスクを軽減するため、強固なユーザー管理とアクセス制御の手法を活用しましょう。

  4. SECURITY.mdファイルを追加する
    プロジェクトのセキュリティ関連情報をまとめたSECURITY.mdファイルを含めましょう。開示ポリシー、セキュリティ更新ポリシー、セキュリティ関連の設定、既知のセキュリティ上の課題、今後の改善内容を記載してください。

  5. Bitbucketアプリを検証する
    サードパーティの開発者が作成したアプリについて、アクセス権、作者や組織の信頼性、全体的なセキュリティ状況を確認しましょう。

  6. Code Insightsを活用し、ワークフロー内でセキュリティのヒントを得る
    Bitbucket Code Insightsを使って、オープン状態のすべてのプルリクエストをスキャンしましょう。PRによって新たに持ち込まれる可能性のある脆弱性を特定できます。

  7. PRにセキュリティテストを追加する
    Bitbucketフックを使って、PRによって新たな脆弱性が持ち込まれないことを確認しましょう。

  8. Bitbucket Pipesにセキュリティテストを追加する
    CI/CDフローにセキュリティスキャン用のPipesを追加し、自動化されたパイプラインでセキュリティの後退が発生しないようにしましょう。

  9. Bitbucket Serverを検討する
    リポジトリの攻撃対象領域を大幅に縮小するには、Bitbucket Serverを使ってリポジトリをオンプレミスでホストできます。

  10. SSHキーと個人用アクセストークンをローテーションする
    Bitbucketへのアクセスには、通常SSHキーまたは個人用アクセストークンを使用します。これらのキーを定期的にローテーションすることで、漏えいしたキーからリポジトリが危険にさらされるリスクを低減できます。

詳しくは、ブログとチートシートをご覧ください。https://snyk.io/blog/cheat-sheet-10-bitbucket-security-best-practices/

構成管理

インフラストラクチャ、システムソフトウェア、さらにはサポートアプリケーションにわたって、一貫した構成を定義・維持する作業は、従来、多くのリソースを必要としてきました。真のDevSecOpsモデルを実現するには、この構成管理を自動化し、開発ライフサイクル全体に統合する必要があります。コードで定義されるコンポーネントが増えたことで、これを実現しやすくなっています。

構成管理を統合・自動化すると、いくつもの重要なメリットが得られます。まず、環境の変更を容易に可視化し、レポートできます。変更管理の代わりにはなりませんが、適切な追跡を確実に行えます。また、この自動化により詳細なバージョン管理が可能になり、インフラストラクチャやサポートソフトウェアの変更を、それらがサポートするコードのバージョンに関連付けられます。これにより、構成の不一致がソフトウェア障害を引き起こす問題を防げます。さらに、構成管理を自動化することで、環境全体で一貫した設定を確保できます。脅威の存在を特定し、セキュリティインシデントに対応しやすくなるという副次的なメリットもあります。

組織が構成管理の自動化導入を準備する際には、検討すべき重要な要素がいくつかあります。

オーケストレーション

インフラストラクチャ・アズ・コードと統合された自動構成管理の大きな利点の1つは、必要に応じてインフラストラクチャのデプロイを自動化できることです。仮想マシン環境、クラウド環境、コンテナのいずれを利用していても、インフラストラクチャのデプロイを動的にオーケストレーションするソリューションがあります。DevSecOpsモデルへの移行にあたっては、こうしたデプロイの範囲を把握し、アプリケーションに適したツールを活用する必要があります。

「Kubernetesクラスターの保護」というタイトルのグラフ。Kubernetesユーザーが実施しているセキュリティ対策を示し、YAML/JSONの手動レビューは42%。
2020年のState of Open Source Securityレポートでは、回答者の44%がKubernetesを使用していると回答しましたが、一般的なセキュリティプラクティスは広く実施されていません。

ホストの堅牢化

ホストの堅牢化は新しい取り組みではありませんが、もっと広く実践されていれば、不要なサービスやアプリケーションが公開される事態を減らせたでしょう。動的なオーケストレーション型インフラストラクチャの普及に伴い、この取り組みは一層重要になっています。基本的な攻撃を自動化ツールに成功させるような、一般的な攻撃対象領域を放置したことに直接起因するセキュリティインシデントは数多くあります。多くのテクノロジーでは、攻撃対象領域を縮小し、信頼モデルを強化するための堅牢化のベストプラクティスや手法が十分に確立されており、テンプレートの作成に簡単に組み込めます。後者はメタデータとしてコード化し、CIパイプラインでさらに処理したり、パッチ適用などのほかのプロセスに活用したりできます。

テクノロジー特集：Dockerイメージのセキュリティ対策

クラウドネイティブ環境に移行する組織が増えるにつれて、コンテナの利用は急速に拡大しています。Dockerイメージが広く普及する一方で、安全でないコンテナイメージによる侵害も増えています。Dockerイメージのセキュリティを確保するため、次のベストプラクティスに従いましょう。

  1. コンテナイメージを最小限にする
    攻撃対象領域全体を縮小するため、OSライブラリやツールが少ないイメージを選びましょう。可能な場合は、フルサイズのOSイメージではなく、Alpineベースのイメージを利用してください。

  2. ユーザー権限を制限する
    イメージ上に専用のユーザーとグループを作成し、アプリケーションの実行に必要な最小限の権限を付与します。プロセスの実行にも同じユーザーを使用してください。

  3. コンテナイメージに署名し、検証する
    イメージの作成時にデジタル署名を行い、公開元からイメージを取得する際に、その信頼性と真正性を検証しましょう。

  4. オープンソースの脆弱性がないか、イメージを定期的に監視する
    既知の脆弱性がないかDockerイメージをスキャンし、スキャンを継続的インテグレーション環境に統合しましょう。

  5. 情報漏えいからイメージを保護する
    イメージのビルド時に、トークン、キー、その他のシークレットがイメージ内に残ることがよくあります。これを防ぐには、マルチステージビルドを使用し、Docker secrets機能を活用して、機密ファイルをキャッシュせずにマウントしましょう。また、.dockerignoreファイルを使用すれば、ビルドコンテキスト内の機密ファイルを取り込むCOPY命令を防ぐのに役立ちます。

  6. 不変性を保つ固定タグを使用する
    同じタグに新しいバージョンのイメージがプッシュされると、ビルド時に一貫性のないイメージが使われる可能性があります。これを防ぐには、バージョンとOSの両方を含む詳細なイメージタグを使うか、コンテンツのハッシュをタグとして使用しましょう。

  7. ADDではなくCOPYを使用する
    ADD命令は、中間者攻撃やZip Slip攻撃など、複数の攻撃経路を生み出す可能性があります。可能な限り、代わりにCOPYを使用してください。

  8. メタデータにはラベルを使用する
    イメージのラベルに追加のメタデータを含めると、ユーザーに役立つ情報を提供できます。また、責任ある情報開示ポリシーに関する情報をイメージラベルに含めることを推奨します。

  9. マルチステージビルドでイメージサイズを最小限にする
    マルチステージビルドを使用して、より小さくクリーンなイメージを作成し、Dockerイメージに含まれる依存関係による攻撃対象領域を最小限に抑えましょう。

  10. リンターを使用する
    静的コード解析ツールを使うことで、Dockerfileのベストプラクティスを徹底し、潜在的な問題を検出できます。

詳しくは、ブログとチートシートをご覧ください。https://snyk.io/blog/10-docker-image-security-best-practices/

このメタデータはコードで定義され、通常はアプリケーションのほかのコードとともにリポジトリに保存されるため、設定内の脆弱性や堅牢化のベストプラクティスからの逸脱を特定できる自動ツールも導入する必要があります。これにより、インフラストラクチャの設計やデプロイにセキュリティを組み込めるだけでなく、開発を妨げることなく実現できます。

パッチ適用のためのCI/CD

各アセットにメタデータが関連付けられたら、組織はそのデータを使い、CI/CDレベルでパッチを適用できます。脅威インテリジェンスや脆弱性管理から得た情報をデプロイ済みのソフトウェアスタックと照合し、テンプレート内の一致を特定して、デプロイ対象としてキューに登録できます。これにより、稼働中のシステムに直接パッチを適用する必要がなくなり、ダウンタイムの影響を抑えられます。また、リスクへの露出状況をほぼリアルタイムで把握できます。

セキュアコーディングのプラクティス

すべてのセキュアコーディング標準を、新たなセキュリティ推奨事項に照らして常に確認する必要があります。コードへの変更はすべて、こうした推奨事項に沿っているか検証し、テストしてください。このプロセスでは、ごく小さな変更も見逃せません。これは簡単な作業ではありませんが、こうしたプラクティスのメリットは過小評価すべきではありません。そのメリットは、開発ライフサイクルにおける変更量だけにとどまらないからです。

OWASP Top 10は、このレビューを始めるうえで最適な指針です。コードの変更をQAテストに反映し、自動テストを活用することで、開発チームに適切なタイミングでフィードバックを提供できます。さらに、19の検証ドメインを持つOWASP ASVSは、セキュアなソフトウェア開発に大いに役立ちます。

新しいソフトウェア開発手法やフレームワークが急速に増えるなか、攻撃駆動型開発は、開発者がソフトウェア開発とアプリケーションセキュリティのツール、手法、手順を並行して学べるプロセスを示しています。

アプリケーションレベルの評価

アプリケーションのセキュリティ脆弱性を自動で評価することは、DevSecOpsにおいて重要な要素です。これにより、組織はリスク状況を正確に把握し、攻撃者に悪用される前に脆弱性を修正できます。DevSecOps環境のセキュリティ体制を成熟させるには、次のようなソリューションが役立ちます。

ソースコードスキャン

ソースコードスキャンには、静的アプリケーションセキュリティテスト（SAST）ツールを導入する必要があります。SASTは通常、メインブランチなどのソースコードリポジトリをスキャンして脆弱性を特定し、ソフトウェア構成分析を実施します。新たに追加されたコードを事前にスキャンして脆弱性を検出できるよう、SASTツールをコミット後のプロセスに組み込む必要があります。SASTツールを統合すれば、ソフトウェア開発ライフサイクルの早い段階で脆弱性を修正でき、アプリケーションのリスクと攻撃対象領域を低減できます。

動的アプリケーションスキャンツール（DAST）

動的アプリケーションスキャンツールは、ステージング環境や本番環境で稼働中のWebサイトをスキャンし、入力フィールドやフォームなど、Webアプリケーションのさまざまな要素に脆弱性がないかを分析します。リリースを次の環境にデプロイする際に、これらのツールをパイプラインに組み込む必要があります。

SASTのIDE連携

静的コード解析プラグインをIDEに連携すると、開発者は統合開発環境内で安全でないコーディング慣行についてほぼリアルタイムに通知を受け取れます。開発環境を離れることなく脆弱性を速やかに最適化し、軽減できる効果的な方法です。

バイナリスキャン

コーディングチェックリストに基づいて、すべてのバイナリにセキュリティ上の問題がないかスキャンし、その後デジタル署名を付与する必要があります。デジタル署名はメタデータと同様に扱われます。たとえばCIでは、署名済みのバイナリのみを使用・実装することで、セキュリティチームの対応待ち時間を設けずに、適切なセキュリティ承認を確保できます。

デプロイ前の監査

アセットの構築に定義済みのテンプレートを使用することは、求めるセキュリティレベルを確保するうえで不可欠です。ただし、ホストベースのスキャンも併用する必要があります。現在、多くのセキュリティスキャナーにはコンプライアンスモジュールがあり、テンプレートをインポートできます。

デプロイ後の監査

インスタンス化した定義済みテンプレートをデプロイ前のスキャン結果と照合し、セキュリティ上の脅威につながる可能性のある変更がないか確認できます。明らかな自動化のメリットを得るため、API連携を利用して実施する必要があります。

脆弱性管理の自動化

脆弱性管理ソリューションは、APIを介してインフラストラクチャやWebアプリケーションのスキャンプラットフォームと連携する必要があります。この連携により、検出されたすべての脆弱性が追跡されていることを組織で確認できます。また、成熟したDevSecOps環境では、特定済みの脆弱性と現在有効な脅威をリアルタイムで関連付けられます。これにより、次のことを特定できます。

  1. 既知のエクスプロイトの対象となるアセット。

  2. ビジネスに差し迫ったリスクをもたらす可能性のある新たな脅威。

脆弱性管理プロセスは、開発者が利用するバグ追跡システムとも連携させる必要があります。これにより、脆弱性の発見と同時にバグ記録を作成でき、迅速な修正につながります。

コンプライアンススキャンの自動化

セキュリティ設定を自動で評価すれば、リスクを低減しながら継続的なコンプライアンスを維持できます。システム評価に必要な作業や時間を減らし、コンプライアンスコストを削減できるほか、コンプライアンスデータを社内のGRCツールやヘルプデスクアプリケーションと共有し、コンプライアンス状況を可視化できます。

シークレット管理

情報セキュリティにおける「シークレット」とは、チームが把握しておくべき非公開情報全般を指します。たとえば、データベースやサードパーティのAPIなどです。信頼できる接続を確立するには、認証情報、証明書、APIトークンが必要です。しかし、こうした対策を講じてもシークレットの取り扱いは難しく、ミスやセキュリティ侵害の原因になることも少なくありません。

シークレットの取り扱いを簡単にする方法として、ソースコードに定数を記述する、またはバージョン管理に登録しない設定ファイルにシークレットを保存する方法があります。こうした方法で一部の問題は解決できますが、特に鍵のローテーションに関する新たな課題が生じます。

理想的なのは、同期された暗号化済みの共有パスワードストアです。共有パスワードを使わず、各チームメンバーが個別に復号できます。これを実現するツールとして、GPG（Gnu Privacy Guard）とPassがあります。GPGでは公開鍵基盤を構築でき、メールの暗号化によく使われます。ただし、GPGは扱いが複雑な場合があります。開発者が「標準的なUnixパスワードマネージャー」と呼ぶPassは、GPGを使いやすくするラッパーを提供します。Passでは、1つ以上の秘密鍵を使ってシークレット情報を暗号化できます。暗号化された情報は1つのディレクトリ内にフラットファイルとして保存され、バージョン管理を使って共有できます。これらのツールにより、暗号化され、安全性を保ちながら共有できる情報の保管場所を実現できます。

GPGやPassなどのツールを使ってシークレットを適切に管理することは、DevSecOpsに不可欠です。リクエストから作成、配布までの各段階で、プロセス全体のセキュリティを確保できます。