「DevSecOpsをEnd-to-Endで理解する」WGは、DoDのリファレンスデザインの学習から始まる　～TEC-JのWGメンバーを訪ねて❶

－－ DevSecOpsをワーキンググループ（以下、WG）のテーマに取り上げたのは、どのような理由・動機からですか。

河合　TEC-Jの「セキュリティ」WGでは、2年前からクラウドセキュリティをテーマに取り上げてきました。2019年は「クラウドセキュリティの運用、コンプライアンス」で、2020年は「クラウドにおける暗号化」です。今年度もその延長として、以前から取り上げたいと思っていたDevSecOpsをテーマにしました。

一般的にDevOpsというとアプリケーションの開発からインフラ運用・保守までを含めた話ですが、DevSecOpsになると随所にセキュリティの話が加わります。これからの時代、早い段階から、そして、あらゆる場面でのセキュリティの考慮が重要なので、取り上げたいと思っていました。

もう1つの理由は、IBMではDevとSecとOpsが組織的にはっきり分かれているので、Devの人がSecを、Secの人がDevやOpsを担当する経験はめったにありません。DevSecOpsは今後より広く使われていくでしょうから、今のうちにきちんと理解しておくほうがよいと考えたのが、今年度に取り上げた理由です。

私はインフラ系メインですが、メンバー募集の案内文では、アプリケーション開発系の人にも参加してもらいたいと思って、あえて「エンド・ツー・エンド」という言葉を入れました。アプリケーションの設計から運用サイクルに乗せるまでのすべてのフェーズでセキュリティを考える、つまり「エンド・ツー・エンド」でクラウドセキュリティを研究するWGであることをアピールしました。

－－　どんな活動プランを立てているのですか。

河合　4月23日にキックオフを行い、5～7月は“リファレンス・アーキテチャの学習”をテーマに米国防総省（DoD）の「DoD Enterprise DevSecOps Reference Design」を読みます。次の7～10月は“ツールの学習”をテーマにCSA(Cloud Security Alliance)の「OSS マッピング」やDevOps Tool資格などを調査し、10～1月はクラウド上での実装、1～3月に成果物を作成するというスケジュールです。途中、実例の紹介などでゲストスピーカーをお呼びすることも考えています。現在は1人1章程度担当の輪講形式で「DoD Enterprise DevSecOps Reference Design」を読み進めています。

 

－－　最初は“リファレンス・アーキテチャの学習”なのですね。

河合　私はアーキテクトなので、いきなりツールの話へいくのは抵抗があって、最初は少し抽象度を上げて考え方から理解したいと思いました。そこで何を教材にしようかなと思っていたところへ先輩から教えられたのが、DoDの「Reference Design」です。

 

－－　どんな内容なのですか。

河合　米国防総省で使われているDevSecOpsを体系化してリファレンス・アーキテクチャにしたものです。最初にソフトウェアライフサイクルの各フェーズにセキュリティを組み込んで自動化するための「コンセプト（概念）」を詳しく述べていて、それから開発、ビルド、テスト、リリース、デプロイ、運用、モニタリングまでの一連のプロセスにおけるアクティビティに触れ、さらにコンテナにも言及し、最後にリファレンスデザインについて解説しています。

－－　村田さんは第3章の輪講の担当ですね。どんな感想でしたか。

村田　DevSecOpsのリファレンスデザインということだったので、読む前はツールの話が満載なのかなと想像していました。ところが組織文化の話だったり、DevSecOpsはトップダウンだけでなくボトムアップも重要というようなことが強調されていて、DevSecOpsの概念が覆されるような感動を覚えました。

それと、「次世代ガバナンスのための5原則」というパートの中に「早めに失敗して、早めに直して、とりあえず前に行く（Fail fast,fail small,and fail forward）」という記述があって、DoDというと失敗を許さないような厳格なイメージがあったので、DoDもこういう考え方をするのだなと、新しい発見もありました。

河合　そこは私も意外でした。DoDにはものすごく堅いイメージがありますからね。DoDがこんな柔軟な考え方を公にするのか、と私も思いました。　

－－　DoDの「Reference Design」の後は、ツールの学習へと進むのですね。

河合　はい。「Reference Design」はあくまでもリファレンスデザインの話なので、ツールへの言及はほとんどありません。せいぜいCI/CD用のツールがあるとか、アーティファクトのためのソフトウェアリポジトリが必要といった記述にとどまっています。それでツールの勉強へと進みます。

ただし、「Reference Design」とツールの学習の間にワンクッション入れたほうがいいかなと思い始めています。

－－　というと。

河合　DoDの「Reference Design」はDevSecOpsの考え方と進め方のリファレンスなので、個々のフェーズでどのようなセキュリティリスクがあるのか詳しく言及していないのです。そこを一度おさらいしておく必要があると感じています。“リファレンスデザインを理解したので、ツールを調べて実装へ進みましょう”になると、DevOpsのやり方になってしまいます。DevSecOpsではセキュリティリスクを考慮することが大事なので、この場面ではこういうリスクがあるということをきちん理解しておきたいと思っています。

－－　ツールの学習ではどのようなことをやるのですか。

河合　DevSecOpsの選択肢としてどういうツールがあるのか、そのツールの特性や得手不得手を調べる予定です。とはいえ、DevSecOpsの世界はツールの流行り廃りが激しいので、勉強しづらいとも感じています。ちょっと前までよく目にしていた製品の名前を今はまったく見かけないとか、聞いたこともないツールが突如としてクローズアップされているということがよくあります。何を調査対象とするか、オープンソースに詳しい人の知恵を借りたり、CSAが公開している資料などを使って絞ってみるつもりです。

－－　そして実装へ進むのですね。

河合　DevSecOpsは全体がシームレスにつながってこそ意味があるので、実装は重要だと考えています。こちらのアウトプットが次のフェーズのインプットになって自動化が進んでいくというイメージですね。ただし言うは易しで、実際にツールチェーンを作るのは、そう簡単ではないはずです。今はコミュニティ版のOpenShiftや無償枠で使えるクラウドサービスもたくさんあるので、いろいろ試したいと思っています。

－－　村田さんはWGに参加されて、どんなことを感じていますか。

村田　河合さんのWGには2019年から参加しているのですが、そのことを私の所属長が知っておられて、WGの活動と関係がありそうな案件にアサインしてくださることが増えました。WGは自分のための勉強の場ですが、実際の業務につながっているところがあります。

WGへの参加を通して一番効果を感じているのは、WGではテクノロジーや各種ガイドの背景や考え方からスタディできるので、今まで以上に”考えながら”仕事に取り組めていることです。最近は、セキュリティ関連のテクノロジーとセキュリティ・プロセスのどちらかに偏ることなく両輪でやっていきたいという思いが強いですね。

河合　そのことはとても大事ですね。セキュリティの担当者は、セキュリティの決め事にがんじがらめになっているところがありますが、決め事は状況が変われば実情に合わなくなることもあるので、テクノロジーを理解して継続的に改善していくことが必要だろうと思います。

－－　WGの最終フェーズは“成果物の作成”ですね。

河合　メンバーには毎年、担当分野の成果を資料化してもらい、それをIBM社内のアセット登録場所にアップして公開するということをやっています。またQiitaのようなエンジニアサイトへの投稿やTEC-Jのショーケースでの発表なども考えています。

－－　今後の計画は？

村田　このWGで得たことを部門や仕事のメンバーに持ち帰り今後の活動に役立てたいと考えています。特にメンバーのスキルアップを促進するには、まず自分が勉強をやめないことだと肝に銘じています。

河合　私のほうは、WGメンバーにインフラ系の人が多いので、最近のクラウドネイティブアプリケーションが持つべき特性やWeb アプリケーションの脆弱性の話を1回入れてDevSecOpsを身近に感じてもらおうと思っています。テキストとしては「Twelve-Factor App」や「OWASP Top 10」を想定しています。

 

◎参考

・「DoD Enterprise DevSecOps Reference Design」
https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf

・「CSA ガイダンス version 4.0 を用いたクラウドセキュリティリファレンス（OSS マッピング 2019）」
https://cloudsecurityalliance.jp/WG_PUB/cloudsecurity_WG/CSAguidance_mapping_20190226.pdf

・DevOps Tools Engineer Objectives V1
https://wiki.lpi.org/wiki/DevOps_Tools_Engineer_Objectives_V1

・Twelve-Factor App
https://12factor.net/ja/

・OWASP Top 10
https://owasp.org/www-project-top-ten/

---

河合 淳一 氏

日本アイ・ビー・エム株式会社
グローバル・テクノロジー・サービス
IGAサービス・マネージメント
シニア・アーキテクト、CISSP、CCSP
TEC-J Steering Committeeメンバー

1995年日本IBM入社。同社社内システムの設計、保守に長く従事、社内事例の紹介も行う。直近10年はセキュリティにフォーカス、セキュリティの上位資格CISSP、CCSPを保持。社内アーキテクチャ研修講師やTEC-J Steering Committeeでワーキンググループ推進リーダーも務める。

村田 紗矢子 氏

日本アイ・ビー・エム株式会社
グローバル・テクノロジー・サービス
セキュリティ&リスクマネジメント
アドバイザリー・ITスペシャリスト

2002年日本IBM入社。入社時より、弊社アウトソーシング・サービスのセキュリティ・デリバリーに従事。セキュリティ・ポリシーの適用にあたり、プロセス／ツールの両面に携わる。さまざまななタイプのメンバーがいるからこそ、仕事がおもしろいのだと実感中。CISA（公認情報システム監査人）/CISMを保持。