ブログ

DevOps におけるセキュリティの転換は考え方の転換を意味する

ロバート・ヘインズ サムネイル
ロバート・ヘインズ
2019年11月15日公開

ずっと昔、私がまだ若くて愚かな UNIX システム管理者だった頃 (今ではただの愚か者ですが)、バックアップ システムを実行するサーバーの 1 つで、かなり重大なセキュリティ上のミスを犯しました。 詳細は省きますが、これは sudo コマンド、テキスト エディター、そして無知に関係していました。

幸運なことに、より経験豊富な(そして率直に言ってより賢い)システム管理者の 1 人が私をサポートしてくれました。 彼らは私の新しい手順に気づき、それを調べ、そして丁寧に私を呼び出して私のやり方の誤りを説明してくれました。 その後、彼らは時間をかけて、人々が必要とするセルフサービス機能を提供しながらも、大惨事の可能性が少ないソリューションを考案するのを手伝ってくれました。 私自身が編集した、信頼できない記憶ではありますが、私自身にとっても、私の設定にとっても、改善された点に感謝しました。

共有、コラボレーション、非難のないトラブルシューティングという行動は、長年にわたって私の中に残っており、セキュリティ上のミスで誰かを助けることができたらいいなと思っています。  

この点に関して、 Puppet State of DevOps レポートを読んでいて、セキュリティをソフトウェア配信ライフサイクルの早い段階で統合すると、結果としてセキュリティが向上することがわかっても驚きではありませんでした。

レポートを見ると、セキュリティをソフトウェア ライフサイクルにシフトレフトする利点は、セキュリティ ツールをパイプラインに移行することと同程度、あるいはそれ以上に、DevOps の動作原則をセキュリティ チームに移行することに依存していることが明らかです。

従来のセキュリティ運用プラクティスではテストと制御に重点を置いていますが (ほとんどのアプリ チームは、対処が必要な複数の問題を示すツール生成のセキュリティ レポートを受け取った経験があるでしょう)、DevOps の原則に基づいて構築されたアプローチでは、早期のコラボレーション、共有、共同責任が奨励されます。

レポートの「セキュリティ体制の改善」セクション (31 ページ以降) を見ると、適切な制御とテクノロジーを導入するだけでなく、ソフトウェアとインフラストラクチャの設計と構築にセキュリティの考え方をスムーズに取り入れることにどれほど依存しているかを理解することが重要です。

セキュリティ専門家のスキルと考え方をソフトウェア配信パイプラインの中核に共有し統合することでメリットが得られるのであれば、最も重要な変化のいくつかは行動面のものになるでしょう。

セキュリティ チームをソフトウェア開発ライフサイクルの早い段階から組み込むには、当然ながら適応が必要になりますが、こうした変更は双方向で行う必要があります。 セキュリティ専門家は新しい作業方法を採用する必要があり、おそらく現在よりも「開発」の言葉を多く話すことを学ぶ必要がある一方で、開発チームはAndon コードの Tao を受け入れる必要があるかもしれません。

アンドンコードと、トヨタが先駆けて導入した品質管理製造プロセスにおけるその位置づけについてまだ調査したことがないなら、調べてみる価値は十分あります。 この主題を扱った記事、学術論文、書籍、さらには高等教育コースもあります。 しかし、あなたがいつも自分に約束していた MBA 取得のためにテクノロジーのキャリアを捨てる前に、この記事を読み終えてください。なぜなら、Andon コードに関する最も重要な事実は、達成するのが最も簡単であると同時に最も難しいことだと私は思うからです。

生産ラインの作業員が欠陥のためアンドンコードを引いて生産を停止すると、同僚や経営陣がまず最初にすることは、作業員に駆け寄って感謝の意を伝えることです。 そして彼らは本気でそう思っているはずです。 アンドンの紐を引くことは、品質向上への一歩であるため、良いこととして受け入れられています。 管理者や同僚は、問題により生産ラインが停止したことに感謝しています。なぜなら、それは改善の機会だからです。

あなたの開発チームは、セキュリティ チームが欠陥を見つけて (仮想) コードを引っ張っていることを感謝の気持ちで受け入れることができますか? DevOps チームは、セキュリティ テストに合格したものと同様に、セキュリティ テストに不合格になったビルドやデプロイメントも評価することを学ぶことができますか?

期待に満ちたビジネス オーナーは、優れたソフトウェアを作成するには、デプロイメントで問題が明らかになる前に問題を特定する、より優れたテストを構築しながら、より頻繁なテストの失敗を探す必要があることを理解できるでしょうか。

それは難しい精神的適応となる可能性があります。

皆さんがこの記事を読む頃には、必然的に編集による修正が加えられていることに感謝はしていますが、自分が作成したものが他の人に分析されるのを見るのは必ずしも容易なことではありません。 理性的な脳はそれがより良い製品を提供することを知っているが、あなたの内なるチンパンジーはただ腕を振り回したいだけなのだ。

したがって、これは採用するのが難しい考え方かもしれませんが、ソフトウェア ライフサイクルの早い段階でセキュリティを統合することに成功するためには非常に重要であり、既存の事後レビューや慌ただしい修復よりもはるかに優れています。

態度を変えることは全く別の研究分野ですが、特に働き方が革命的に変化しているこの時代に、IT のリーダーや実務者はこの分野に習熟する必要があります。 多くの場合、新しいテクノロジーを導入するよりも(はるかに)困難です。 セキュリティに関して「シフト レフト」を成功させるには (このレポートのデータではそうすべきだと示されています)、技術的な要素と同じくらい人的要素にも時間をかける必要があります。