クラウドセキュリティ会社の運用のプロとして、私はオペレーションとセキュリティを同時に実現できるかどうか―理想的な世界においてそうすべき―ということについて独自の視点を持っています。今日のハイテク業界で見られる共通の問題の1つは、開発プロセスにおいてセキュリティの実現がほとんどいつも遅れているということです。
セキュリティというのは完全に別個の規律なので、それをタイトなDevOpsフィードバックループに組み込むことは難しく思えるかもしれません。しかし、それは可能なだけでなく、思ったほど難しくないということをここで伝えたいと思います。そして、それを普通に行えれば、多くの問題を除去しながら全体的なセキュリティ方針に大きな違いをもたらします。
特に、「シフトレフト」というコンセプトは、チームが以前にデプロイプロセスの後半で行っていたセキュリティ導入プロセスを早期に組み込むことを可能にします。この記事では、これを行う方法について説明します。
「遅すぎる」とはどういう意味か
まず、今日DevOpsプロセスにセキュリティがどのようにもたらされているかを見てみましょう。実際は多くの場合そうなってはいません。これは、エンジニアが準備できたコードをデプロイするとき、セキュリティプロセスはまったく含まれていないことを示しています。もちろん、これを行う開発者は自分の仕事をしているだけです。彼らは製品チームから機能をリリースするという圧力を受けています。できるだけ早くコードを書き上げるために、自分がしなければならないことをやっているだけです。
他のケースでは、セキュリティチームが投入され、門番としてコードが外に出る前にセキュリティレビューを行うことがあります。セキュリティ要員が呼ばれて、欠陥があるかどうかを確認することは良いことです。しかし、最後の最後まで待つことは、継続的デリバリーのサイクルを妨げる可能性があり、今日のアジャイルな開発風土では選択肢とはなりえません。言うまでもなく、それはお互いを対立する立場に立たせることになり、チーム間の緊張につながる可能性があります。
いかにして「シフトレフト」するか
ここ数年、DevOpsチームをよりスピードアップし、継続的デリバリーで開発するよう最適化している組織がますます増えています。しかし、今はセキュリティを織り込む時です。それが「シフトレフト」です。
今までは、
Devチームが開発を行う → テスト → セキュリティチームがチェック（やらないこともしばしば） → デプロイ
というプロセスだったのを、
Devチームが開発を行う → セキュリティチームがチェック → テスト → デプロイ
というように、セキュリティを確保するプロセスを前段階に組み込むのです。それを実現するためのいくつかのヒントがあります。
同じツールを使用する
セキュリティチームがDevOpsチームが使用するのと同じ継続的インテグレーション／デリバリーのツールに精通していることが重要です。Opsのチームにコードの書き方を教えたり、Chefのような構成管理ツールの使い方をDevチームに教えたりと、DevとOpsのチームが協働するのです。今度はこれをセキュリティで行う番です。
Jenkinsは最適な例です。開発者が既にJenkinsを使用してコードのテストやデプロイをしている場合、セキュリティチームにも使うように教えたらどうでしょうか。彼らがセキュリティテストに同じツールを使用すれば、すぐにそれをプロセス化することができます。
もう1つの素晴らしいツールはGauntltです。「Rugged DevOps」という用語についてはいくつか言いたいことがありますが、Gauntltのアイデアは良いものです。Gauntltのサイトで、
「Gauntltは、さまざまなセキュリティツールを提供し、セキュリティ、Dev、Opsチームで連携させて、堅牢なソフトウェアを構築します。これは、グループ間のテストとコミュニケーションを容易にし、実行可能なテストを作成して、デプロイプロセスとテストプロセスに投入できるようにします」
運用と開発プロセスの途中でセキュリティを導入するというコンセプトは基本的に妥当なものです。この方法では、セキュリティがデプロイを遅らせることはなく、問題が発見されたときのフィードバックループを強化できます。セキュリティチームはGauntltを使用してコードを書き、テストして、継続的デリバリーを容易にします。
スタティック解析を試みる
別のオプションは、Veracodeのようなツールを使ってスタティック解析を試みることです。セキュリティチームは、デプロイの前にコードを解析し、潜在的な問題をキャッチしようとします。スタティック解析は、コードを実行することなくソフトウェアを分析します。セキュリティチームは、デリバリーサイクルを中断することなく、潜在的な脆弱性を自動的にチェックすることができます。
インセンティブを合わせる
歴史的に、DevOpsとセキュリティを連携させるための課題の1つは、相反するインセンティブがあることでした。DevOpsチームはコードを素早く書き上げることが勝利です。セキュリティチームは安全なコードができたときが勝ちです。
所有権を提供する
私たちが抱えている一般的な間違いの1つは、開発にアクセスすることさえできないセキュリティチームがあることです。セキュリティチームがコードに対して直接的な所有権を持たない場合、DevOpsサイクルに緊密に統合されない可能性があります。
一方で、セキュリティチームに所有権を与え、コード内の問題を自分で解決する方法を教えると、サイロ化を免れ、よく油の効いたマシンの一部になることができます。たとえば、 Threat Stackはセキュリティ上の問題についてチームに警告することができます。セキュリティチームに問題を解決する方法を教え、構成管理コードにアクセスできるようにすると、システムに直接アクセスして変更を加えることができるようになります。
同様に、Chef は監査とテストのフレームワークであるInSpecというツールをオープンソース化しています。InSpecを使用すると、セキュリティチームは監査サーバにコードを記述し、コンプライアンスを確保できるようになります。これにより、プロセスに対する直接的な所有権が大幅に強化されます。そして、セキュリティチームの開発スキルを向上させることができます。論より証拠です。
これにアプローチする別の方法（特に専用のセキュリティチームを持たない場合）は、セキュリティ上の脆弱性が発生した場合に、バックエンドのエンジニアにコードの修正を担当させることです。エンジニアがコードの健全性に直接の責任を負っている場合、最初からセキュリティに重点を置く可能性が高いです。Threat Stackでは、2人のOpsと10人のバックエンドのエンジニアがオンコールに従事しています。製品に問題が発生した場合、そのコードを書いたのは通常バックエンドのエンジニアリングチームです。このレベルのコード所有は、最初から正しいものを構築するようなインセンティブを彼らにもたらします。
前に進むことは横に行くこと
セキュリティをシフトレフトすると、ビジネス全体の健康状態が改善されます。セキュリティチームが問題をキャッチしチケットを開いたあと、開発者やOpsの担当者が物事を修正するのを待つのではなく、彼ら自身で解決するような力を与えます。これにより、時間と人員が節約できるだけでなく、コードが安全かつ継続的にリリースされることが保証されます。この方程式が他のチームの仕組みやワークフローにどのようにしっかりと統合されているかを、より積極的に理解できるかは皆さん次第です。
上記のヒントは、組織の現実を「セキュリティをシフトレフトする」ための出発点です。セキュリティの多くの側面と同様に、新しいツールを導入するだけでなく、 文化的な変化も必要であることを覚えておいてください。それにより、正しい考え方、インセンティブ、フィードバックループを適切に実行することができるのです。
本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。
カテゴリー ：ベストプラクティス
