DevOpsのライフサイクルにおいてセキュリティを実装する際にすべきこと、避けること

avatar

 2018.10.29  Japanブログ編集部

DevOpsは、企業がソフトウェア開発を行う方法を再定義しています。また、デジタルリスクを管理しようとするセキュリティのプロにも課題を与えています。そんな中、セキュリティチームは、DevOpsのセキュリティにどのような戦略的アプローチを取るかという選択を迫られています。

DevOpsのライフサイクルにおいてセキュリティを実装する際にすべきこと、避けることについて、専門家は次のように提案しています。

DevOpsのライフサイクルにおいてセキュリティを実装する際にすべきこととは?

  • サイバーセキュリティライター、KIM CRAWLEY氏 | @KIM_CRAWLEYKim-Crawley

責任の所在が決まっていない物事に、注意が払われることはありません。また、与えられない責任を取る人もいません。ソフトウェアの開発プロジェクトの初めには、すべての役割と責任がプロジェクトに関与する各メンバーに明確かつ簡潔に委譲されていることを確認します。

betanewsによると、DevOps部門のメンバーの半数近くが、セキュリティを実装するうえで、責務や責任を明確化することは難しいと考えています。また、セキュリティはDevOpsのライフサイクルにおけるそれぞれのステージに組み込まれる必要があります。

すでに稼働している環境にセキュリティを導入します。エンジニアがすでに使用しているツールを使って、セキュリティプロセスを簡単に開始できるようにします。

私がSlackで勤務していたときに、これを実行していました。また、この方法はスケールアップには不可欠でした。

  • TRIPWIRE R&D部門シニアマネージャー、ANTHONY ISRAEL-DAVIS | @ANTHONY_IDIsrael-Davis-Anthony-Cropped.small_.

DevOpsの素晴らしい点は、多くの従来型のステージゲートを自動化し合理化できることです。このようなステージゲートは、セキュリティとコンプライアンスの観点からも未だに不可欠なコントロールです。責務の分離は依然として重要です。そして、パイプラインは手動のハンドオフポイントであったものを、自動プロセスに組み込むことができます。導入、機能テスト、品質テストおよび展開の実行は、必要に応じてアクセス制御を行い、リスク低減のためにワークフローによってゲート管理すべきです。

たとえば、導入前には、コンテナの脆弱性と設定の安全性をスキャンします。それに合格し、導入が無事に進めば次のステージへと進みます。また、ステージゲートの証拠を保存して、監査担当者が活用できるようにしましょう。

  • PUMA SECURITY社、主席セキュリティエンジニア、ERIC JOHNSON氏 | @EMJOHN20nmkgBXGp_400x400

私はこれまで、数多くの企業で働き、情報セキュリティを学ぶ数十万人の学生とDevSecOpsプログラムについて論じてきました。まず議論したのは、DevSecOpsの文化についてです。

従来のセキュリティの文化は、いつでもNOと言うことができ、組織全体で情報の共有ができず、失敗を許さない文化でした。この文化は、さまざまな作業環境を作り出し、チームに力を与え、共同作業や問題解決を可能にし、Fail fast(速やかに失敗せよ)の精神をもって、継続的に改善を行うというDevOpsの文化とは真逆です。DevSecOpsプログラムを成功させるには、セキュリティチームがこの文化を受け入れる必要があります。セキュリティ部門は、DevOpsチームが迅速に対応し、貢献することを可能にするエンジニアリングプロセスとツールについて理解する必要があります。

多くのセキュリティチームは、ツールのことを理解せずに、急いで事を進めようとして、エンジニアリングのワークフローを混乱させた結果失敗します。確実に成功するためには、セキュリティコントロールを1つずつじっくりと導入し、その結果がチームにとって有益であることを確認します。セキュリティプロセスを継続的に監視・改善して混乱を生じさせないようにすることによって、DevOpsの文化に同化します。また、結果の評価、スキャンツールの微調整、エンジニアリングチームとの協働によって誤検出を最小限に抑えることも必要です。

文化の切り替えを怠ることが、DevSecOpsが失敗する第一の理由なのです。

  • NOPSEC社、戦略&製品マーケティング担当バイスプレジデント、ADRIAN SANABRIA氏 | @SAWABAAdrian-Sanabria

ここ10年間に私が見てきたセキュリティに関するアイデアのうち、最も革新的で独創的なもののいくつかは、DevOps部門から出たものでした。私がお勧めするのは、各DevOpsグループにつき1人をセキュリティの責任者に任命することです。セキュリティがその人物の主な役割でなくても、セキュリティの責任者が存在することで、セキュリティがないがしろにされることはなくなります。

もう1つは、セキュリティおよびコンプライアンスの要件を事前に特定し、それらをできるだけ自動化しておくことです。いくつかの企業では、共有の読み取り専用フォルダーに監査ログが格納されるようにして、監査担当者が提出を依頼しなくても、リアルタイムで参照できるようにしていました。

  • ETHICAL TECH社、共同創業者兼バイスプレジデント、JUSTIN SHERMAN氏 | LINKEDINJustin-Sherman

ソフトウェアの設計プロセスにセキュリティを実装することは絶対不可欠です。ただしそれは、慎重に実装する必要があります。ソフトウェア開発者の大半は、セキュリティに関する適切なトレーニングを受けていません。合理的に考えて、事前の練習もなく、突然安全なソフトウェアを作れるようになることは期待できません。それでも、それを期待したくはなります。

したがって、組織はソフトウェア開発者のセキュリティ対策に関する訓練を慎重に実施し、多大な時間、費用、およびリソースを投資して、それらのタスクを確実に実行できるようにする必要があります。このような投資と教育無しには、セキュリティをDevOpsに組み込む取り組みは、始める前から失敗するでしょう。

  • TRIPWIRE、シニアセキュリティリサーチャー、LANE THAMES | @LANE_THAMESLane-Thames

幸運なことに、コンピューティング業界は、ソフトウェアとシステムを設計・デプロイした後でセキュリティを追加してもうまく機能しないことを学びました。その結果、「セキュリティを組み込む」という考え方に注目が集まり、新しいDevOpsテクノロジーに取り入れられているようです。

「ソフトウェアを作成し、アジャイルおよびDevOpsの方法論を採用している組織は、包括的なセキュリティアプローチと文化を採用する必要がある」と私は考えています。この包括的なアプローチでは、継続的インテグレーション、継続的デプロイメント、継続的デリバリーパイプラインにおけるプレパイプ、インパイプ、ポストパイプの段階でのセキュリティを考慮する必要があります。

プレパイプのアプローチでは、計画およびコーディングの段階におけるソフトウェアのセキュリティを考慮する必要があります。計画段階で通常の機能テストと共にセキュリティベースのテストも一緒に作成する「Secure Test-Driven Development(セキュアなテスト駆動開発)」のようなものが主流になればよいと思います。アジャイルの世界では、自動化が鍵となります。私たちはすでに、ソフトウェアが正確に機能することを確認するためのテストを定義して高品質を保証しています。ソフトウェアのセキュリティは、ソフトウェアの品質における基本的な側面です。初期の段階でセキュリティベースのテストを開発して早めに検討する必要があります。その結果、徐々に、テストの膨大なライブラリが作られ、ビルドおよび関連するテストの自動化を行うインパイプの段階で何度も実行されます。このようなセキュリティ関連のテストのクオリティゲートにより、潜在的な脆弱性が存在するコードが本番環境に入り込むのを阻止できます。

次に、ソフトウェアがインパイププロセスを進む間に、セキュリティをチェックする新しいテクノロジーを統合する必要があります。これには、自動化されたセキュリティ評価(基盤となるOS、サードパーティのライブラリ、およびインストールされたアプリケーションの自動化されたインパイプの脆弱性評価など)に基づいて、パイプライン内にクオリティゲートを追加することが含まれます。また、自動化されたインパイプのアプリケーションレベルの脆弱性評価用クオリティゲートも含める必要があります。この評価ではパイプ内にプルされる実際のコードの静的あるいは動的分析を行います。

最後に、ポストパイプのセキュリティに焦点を当てなければなりません。アジャイルおよびDevOpsの方法論において、自動化は必要不可欠ですが、それですべてが解決されるわけではありません。ここで大いに関与するのが、ペネトレーションテスト、構成のコンプライアンス評価、オンラインの脆弱性評価、レッド/ブルーチーム演習、および基本的なコントロールなどの従来型のセキュリティ対策です。

  • TRIPWIRE、テクニカルプロダクトマネージャー、MATT WILLIAMS | @EVERYDAYSECmatt-avatar-1

脅威のモデリング:データがシステム内をどのように動くか、いつ境界を超えるか、そしてどのように悪用される可能性があるかを考える時間を取って視覚化してみましょう。これを製品と、CI/CDパイプライン自体の両方について行います。これにより、セキュリティだけでなく、アーキテクチャー全般が改善されます。

パブリック クラウドインフラストラクチャーを信頼しつつも検証しましょう: パブリッククラウドインフラストラクチャーを適切に利用すれば、開発速度が上がるだけでなくセキュリティも強化できます。適切なプロセスとツールを使用すれば、「パブリック」だから「安全性が低い」ことにはなりません。

  • CONTINUUM SECURITY社、セキュアデザインアナリスト、STUART WINTER-TEAR氏 | @STEGOPAXStuart-

私にとって、DevOpsライフサイクルでのセキュリティの確保のために最も重要なことはコミュニケーションです。

当たり前のことだと思われるかもしれませんが、あまりにも長い間、サイロ化されたセキュリティチームは、開発プロセスの最後に、塀の上から仕事を投げ入られるような状況でした。このような状況から、セキュリティチームは、部族の知識を操る謎めいた部門、あるいはNOと言うばかりのボトルネック的な部署のように捉えられています。

コミュニケーションの第一のステップは、他の言語を学ぶことです。つまり、セキュリティチームは「DevOps」の言葉を学び、彼らが使用しているツールを使ってコミュニケーションを取るようにしなければいけないということです。

コミュニケーションは知識の普及を促進します。そして、その明らかな利点は、セキュリティ上のノウハウを領域の異なるパートナー、つまりアプリケーションの構築と展開を担当する相手に広めることができることです。

コミュニケーションは対面通行です。反論や質問をしたり、コラボレーティブな環境を培うためのスペースを提供する必要があります。

これには「アクティブ・リスニング(積極的傾聴法)」を通して信頼関係を構築することと、それ以上に、DevOpsの同僚から学ぶことが重要です。

私の経験では、脅威のモデリングを活用するとともに、クロスファンクションナルな「セキュリティチャンピオン(開発チーム内のセキュリティ推進リーダー)」を作ることが、DevSecOpsのコミュニケーションプロセスを確立するうえで最も効果的かつ強力な方法であると言えます。

  • LUMAGATE社、CEO兼マネージングパートナー、PETE ZERGER氏 | @PZERGERl6Jeeye1_400x400

DevおよびOpsチーム内のサイバーセキュリティチャンピオンを特定することです。DevOpsのプロセスにセキュリティ(DevSecOps)の焦点を持ちこむことは、セキュリティを理解している人がいない場合には難しくなります。Opsに焦点を当てたセキュリティのプロは、「Infrastructure as Code」およびエンドポイントのセキュリティをより重要視するようになるでしょう。一方で、Devに焦点を当てたセキュリティのプロは、コード内のセキュリティ(暗号化されていない接続文字列など)に精通するようになります。私はOps側の担当者が、開発者が見逃したコードレベルの問題を見つけたのを見たことがあります。DevOpsからDevSecOps間の移行の早い段階で、これらの信頼できる担当者を特定することで、セキュリティ意識がチームのすべてのメンバーとプロセスに浸透します。

その間に、プロセス内で発生するセキュリティの問題に関してDevチームとOpsチームをコーチする際に、相互を尊重したコミュニケーションを取る方法について、サイバーセキュリティチャンピオンを指導します。最後に、健全な議論を培うオープンなコミュニケーションとトーンを求め、チーム内に不安を生み出すような「非難の文化」ではなく、Devチームの段階的な改善を促します。結局、これは旅なであり、DevチームとOpsチームが共に積んでゆく学習経験なのです。そのため誤りも生まれます。そのような誤りが、DevOpsのプロセスとチームメンバー両方の成熟のきっかけとなるよう方向づけを行ってください。

DevOpsのライフサイクルにおいてセキュリティを実装する際に避けるべきこととは?

  • F5 NETWORKS社、主席テクニカルエバンジェリスト、LORI MACVITTIE氏 | @LMACVITTIEloriMacVittie

従来のセキュリティ慣行を持ち込まないようにしましょう。従来型のセキュリティソリューションは、アプリケーションアーキテクチャーに事後的に追加され、ネットワークに密接に結びついています。現在のアプリケーションは、さらに高い柔軟性を必要としており、最終的な展開先において、従来のセキュリティ対策の採用に必要とされるネットワークアーキテクチャー経由ではコントロールすることができない場合があります。セキュリティを確保したいものは何かを考えましょう。アプリなのか、プロトコルスタックなのか、プラットフォームか、それともデータなのか。そして、どのコントロール、ポリシーおよびアプリケーションサービスで必要なセキュリティを実現できるか、またDevOpsパイプラインに統合できるかを考えましょう。

  • TRIPWIRE、IT開発部門マネージャー、CLINT MALSON0-3

私からの最良のアドバイスは、急がないことと、基本的なコントロールを忘れないようにすることです。Tripwireでは、絶え間なく変化する開発者のニーズに応えるDevOps環境を構築するという旅を続けてきました。これまでに何度も、DevOpsを最大限に活用できるよう鼓舞してきました。しかし、それには時間がかかるのが現実です。ゆっくりと初めて、コントロールを構築しましょう。それがいったん形になれば、展開するのは簡単です。今DevOpsが実践できていないからと、準備が整わないうちに事を急ぐのはやめましょう。

  • NEW CONTEXT社、セキュリティサービス部門バイスプレジデント、ANDREW STORMS氏 | @ST0RMZ1-5

セキュリティをDevOpsのパイプラインに実装する段階として一般的なのは結合ステージです。このステージでは、Jenkinsのようなツールを使用して、結合テストを行ったり、静的分析や脆弱性スキャンのようなチェックを行う一般的なセキュリティツールの使用を開始します。セキュリティを重視する人たちが、そのようなセキュリティツールのすべてのパワーを最大限度まで引き出したときに、予想以上の成果が得られることになります。また、自分のコードのセキュリティの不備についてよく理解できるようになるかもしれません。ただし、今や結合テストの所要時間は1分から1時間へと変わっています。

経験から言えることは、セキュリティの実装は徐々に慣らすようにして、1晩で完璧にしようなどと思わないことです。

  • GE DIGITAL社、シニアサイバーセキュリティリーダー、CAROLYN TAISEY LEAR氏 | LINKEDINCarolynTaiseyLear

ツールを決定する重要な局面ではDevOpsチームを排除しないようにしましょう。DevOpsチームをパートナーとして認識しましょう。

セキュリティツールやスキャナーのCI/CDパイプラインへの統合に関する概念実証の場面では、DevOpsチームの関与が不可欠です。

  1. DevOpsチームから要求・要件を聴き取りして評価しましょう。例:拡張性、OSの統合要件およびパッチの適用やアップデートなどの管理
  2. ベンダー参加のツールのテクニカルレビューを行う際に、メンバーにDevOpsチームを加えます。これにより、重要な評価の時間を短縮できます。
  3. ベンダー契約のレビュアーとして、DevOpsのメンバーを必ず加えるようにします。彼らはどのようにコードのビルドとプッシュを行うかを知っています。それにより適切なライセンスアプローチを実現できます。

常にDevOpsチームをパートナーとして扱い、さらなる成功と戦略的な方向性を獲得しましょう。各プロジェクトや取り組みが完了すると、その相乗効果が定着するようになります。

  • TRIPWIRE、ソフトウェアエンジニア、BOB THOMAS | LINKEDINBob-Thomas

「DevOpsチーム」を使うだけ使って、他のプロセスを変えなければ、DevOpsは失敗します。古い文化やプロセスを変えずにDevOpsを成功させることはできないように、従来型のITセキュリティと同じプロセスを続けていれば、DevOpsにセキュリティを統合することはできません。DevSecOpsチームはセキュアな開発およびオペレーションの実行に関するトレーニングを受ける必要があります。そのようにして、セキュリティがリリース前の承認ゲートだけでなく、プロセス全体に組み込まれるようにするのです。

  • 情報セキュリティアーキテクト、WEBアプリペンテスター兼開発者、SUNNY WEAR氏 Sunny-Wear@SUNNYWEAR

企業がDevOpsのパイプラインにセキュリティを組み込もうとする一方で、組織のリーダーは、従来の教育環境で、プログラマーに安全なコーディングテクニックを学ばせようとしています。しかし、それでは期待通りの効果は望めません。問題の一端は、安全なプログラミングとは、本来は文脈的なものであり、言語、フレームワーク、またはバージョンに密接に関連しているということです。セキュアなコードを実現するためのトレーニングが成功するには、開発者が日々の業務で行うような自然な方法で学習しなければなりません。インタラクティブな静的コードアシスタントのプラグインを使用するのも1つの手です。

インタラクティブな静的コードアシスタントは、最も一般的な統合開発環境(IDE)で利用できるプラグインです。このプラグインは、問題となるコード行に対して、即時のコード警告、リスクの詳細な説明、自動生成のコードフィックスをポップアップ表示します。2017年のTabassum、Watson、Lipfordによる調査では、コーディング中にIDEプラグインを使用するプログラマーのセキュリティ意識が向上することが明らかにされています。このようなプラグインは、安全なコードを記述する機会や、安全なプログラミングについて学ぶ機会を提供します。

安全なコード作成を学ぶための唯一の手段として、従来の授業形式での学習を選択することは避けるべきです。代わりに、OWASP ASIDE/ESIDE、Puma、SonarQubeなどのインタラクティブな静的コードプラグインの使用を検討して、安全なコーディングテクニックに対するプログラマーの知識向上に努めましょう。

Tripwireのソリューションを使用して、どのようにDevOpsのセキュリティへのよりスマートなアプローチを取れるようになるかを知るには、こちらをクリックしてください。

SANS:基本への回帰

RECOMMEND関連記事


この記事が気に入ったらいいねしよう!