セキュリティ診断だけでは不十分？アジャイル開発やDevOpsのセキュリティ対策

ラックではセキュリティ対策サービスだけでなく、WebアプリケーションやWebサイトなどを始めとした企業情報システムの開発や運用を行うシステムインテグレーションサービスを提供しています。Webアプリケーション開発とセキュリティ分野におけるラックの「御意見番」である3人が、「アプリケーション開発のセキュリティはどうあるべきか？」をテーマに、Webアプリケーションセキュリティのこれまでとこれからをリレー形式で語ります。

最終回はエンタープライズ事業部セキュリティサービスグループの永井が担当します。永井は、多数のWebアプリケーションの開発を経験後、フレームワーク開発や大規模システム開発案件にアーキテクトとして従事してきました。その経験を活かして、現在はシステム開発の上流工程から運用までを幅広くカバーするセキュリティ対策サービスを提供しています。

DevSecOps

アプリケーション開発チームと運用チームとの協調（DevOps）に、セキュリティチームも加わることをDevSecOpsと呼びます。ラックでは、アジャイル開発やDevSecOpsを推進する場合のセキュリティ対策サービスを提供しています。

アジャイル開発の場合、開発からリリースまでの期間が短く、リリースを数多く実施します。そのため、外部のセキュリティベンダに毎回セキュリティ診断を委託するのは現実的ではありません。そこで、ラックが提供するシステムセキュリティデザインサービスを使うと、このようなアジャイル開発の課題解決ができます。この記事では、アジャイル開発やDevOpsを推進するシステム開発の現場で活用されている、システムセキュリティデザインサービスについて詳しくご説明します。

セキュリティ要件のガイドラインを整理しよう

Webアプリケーションの構成要素には、アプリケーション、プラットホーム、ネットワークなどの構成要素があります。アジャイル開発では、1〜2週間といった非常に短い単位で開発を進めていきます。このサイクルをアジャイル開発でよく使われる「スクラム」では、スプリントと呼びます。スプリントで開発する機能を優先度の高い順から選択して、選択した機能の開発とリリースを繰り返していきます。しかし、以下表のような非機能要件は、ある程度事前に検討して環境を準備していく必要があります。

大項目	大項目	中項目	説明
可用性	継続性、耐障害性、災害対策、回復性	システムサービスを継続的に利用可能とするための要求
性能・拡張性	業務処理量、性能目標値、リソース拡張性、性能品質保証	システムの性能、および将来のシステム拡張に関する要求
運用・保守性	通常運用、保守運用、障害時運用、運用環境、サポート体制、その他の運用管理方針	システムの運用と保守のサービスに関する要求
移行性	移行時期、移行方式、移行対象（機器）、移行対象（データ）、移行計画	現行システム資産の移行に関する要求
セキュリティ	前提条件・制約条件、セキュリティリスク分析、セキュリティ診断、セキュリティリスク管理、アクセス・利用制限、データの秘匿、不正追跡・監視、ネットワーク対策、マルウェア対策、Web対策、セキュリティインシデント対応/復旧	情報システムの安全性の確保に関する要求
システム環境・ エコロジー	システム制約/前提条件、システム特性、適合規格、機材設置環境条件、環境マネージメント	システムの設置環境やエコロジーに関する要求

非機能要件定義として挙げた例は、情報処理推進機構（IPA）が公開している「非機能要求グレード2018」から抜粋したものです。ラックのシステムセキュリティデザインサービスでは、このうちセキュリティに関わる範囲をセキュリティ要件として整理しています。

※ システム構築の上流工程強化（非機能要求グレード）：IPA 独立行政法人 情報処理推進機構

セキュリティ要件の作成においては、開発アプリケーションの特性に応じて、次表のような業界標準や、監督官庁の提示している基準やガイドラインを参考にする必要もあります。

適用例	要求仕様	刊行	特徴
金融業界向け	金融機関等コンピュータシステムの安全対策基準・解説書 第9版​	金融情報システムセンター​（FISC）	金融業界向け対策基準で、主に銀行が広く利用される対策基準
	金融分野における個人情報保護に関するガイドライン	金融庁	金融業界向け対策基準で、金融業界全般で利用されるガイドライン
Webアプリのセキュリティ対策	安全なウェブサイトの作り方	情報処理推進機構（IPA）	官公庁、公共のシステム構築案件に多く用いられるセキュリティ対策の要求仕様
認証、認可	NIST Special Publication 800-63-3: Digital Authentication Guideline	米国立標準技術研究所	ダイレクトバンキング等でも用いられる、サービス利用ユーザのライフサイクルに関する要求仕様
ネイティブアプリ （スマホアプリ）	OWASP Mobile Application Security Verification Standard	OpenWebApplicationSecurityProject	スマホネイティブアプリ開発時に、多く用いられる要求仕様
アプリケーションのセキュリティ対策	OWASP ASVS（アプリケーションセキュリティ検証標準）	OpenWebApplicationSecurityProject	金銭取引が行われるシステム構築時に、多く用いられる要求仕様
クラウド運用	ISO27017	日本品質保証機構	クラウドの利用/提供に関するセキュリティ要求事項を定めた規格
システム非機能要求事項全般	非機能要求グレード2018	情報処理推進機構（IPA）	機密性、可用性、完全性等の観点でシステムの非機能要求事項を定めたガイドライン
データの秘匿化や暗号化	電子政府推奨暗号リスト	CRYPTREC	総務省、及び経済産業省が推奨する暗号技術の評価

参照すべきガイドラインや基準は多岐に渡り、随時更新されていきます。こうしたガイドラインや基準には、具体的な実装方式などは記載されていないこともあるので、ガイドラインや基準を満たす実装方式についても情報収集と判断が必要になります。ラックのセキュリティコンサルティングサービスは、様々な業界のお客様を支援していますので、常に最新の業界動向に応じた要件と、具体的な実装方法を提示することが可能です。

アプリケーション開発中のセキュリティレビュー

それでは、アプリケーション開発チームがスプリントを回しているときに、私たちセキュリティエンジニアは何をしているかをご紹介しましょう。開発スプリント中は、主に当該スプリントで開発している機能についてセキュリティ面からのレビューを実施します。

セキュリティレビューを実施する際には、「データ入出力」「通信」「振る舞い」の3つの観点で実施します。アプリケーション開発の初期段階からセキュリティエンジニアが開発チームと一緒に仕事をすることで、早期にセキュリティ上の問題を解消できます。また、セキュリテエンジニアの側から見ても、少しずつレビューの範囲を広げていけるので、1回あたりのレビューの生産性を向上できます。

1. データ入出力

• 新たなデータベースへの入出力はあるか
• テーブルやカラムの追加によるSQL文の追加、変更はあるか
• 情報のファイルやメールへの出力はあるか

以上のようなデータ入出力の変更点を確認して、変更がある場合は内容を確認します。

2. 通信

Webアプリケーションが使用している既存のプロトコル、ポート以外にネットワークを利用したデータのやりとりがないかを確認して、新たな通信を利用している場合は内容を確認します。

3. 振る舞い

振る舞いの観点については、大きく機能を変更、追加する箇所は内容を確認して、それ以外は補足で静的セキュリティ診断（SAST）ツールの診断結果の内容をレビューで確認します。

セキュリティ対策のセルフサービス化を進める

アプリケーション開発やシステム運用のエンジニアに比べて、セキュリティエンジニアの人数は圧倒的に少ないのが現状です。アジャイル開発やDevOpsでアプリケーション開発のスピードが上がっていくときに、セキュリティがボトルネックになってはいけません。そこでアプリケーション開発者が、セキュリティ対策をセルフサービスで行える環境を整備し、セキュリティに関するトレーニングや教育を提供していきます。

たとえば、設計の際に開発者自身で確認できるセキュリティチェックシートを、自社の環境に合わせて取捨選択して整理し、開発者が利用できるように整備しておきます。IPAの「安全なウェブサイトの作り方」と別冊の「安全なSQLの呼び出し方」「ウェブ健康診断仕様」や、脆弱性診断士スキルマッププロジェクトの「Webアプリケーション脆弱性診断ガイドライン」などが参考になります。

※ 安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構
※ GitHub - ueno1000/WebAppPentestGuidelines: Webアプリケーション脆弱性診断ガイドライン

セキュリティ対策のセルフサービス化を更に進め、セキュリティ診断もセルフサービスにする場合もあります。SAST（Static Application Security Testing：静的アプリケーションセキュリティテスト）やDAST（Dynamic Application Security Test：動的アプリケーションセキュリティテスト）を行うセキュリティ診断ツールを導入し、プロジェクト内でセキュリティ診断を実施できるようにします。こうした「セキュリティ診断の内製化」を進める場合、セキュリティ診断ツールの選定に加えて、次のようなことも考慮しておくと良いでしょう。

• サイト管理者へどのような確認をして、どのような報告を行えばよいのか
• セキュリティ診断システムを維持運用する業務は誰がどのように行うのか
• セキュリティ診断作業にかかるコストをチェックする指標はどのように定めるのか

こうしたセキュリティ診断ツールを用いた、「システム運用業務」と同じような設計、実装が必要になります。
診断業務も「人」、「物」、「プロセス」の観点で、診断業務の運用準備を行うと良いでしょう。

人	物	プロセス（運用業務）
診断員 システム運用員 スーパーバイザー スキルリーダー チームリーダー	診断ツール システム監視ツール 運用プロセス管理ツール ファイル管理ツール コミュニケーションツール 業務ネットワーク その他ファシリティ （ICカードリーダ、カード）	診断業務 システム維持運用 運用プロセス管理 運用品質維持

さいごに

今回の記事では、多くのお客様と共に進めてきた、DevSecOpsの実現に向けた各工程の施策と知見をご紹介しました。アプリケーション開発と運用の主流となりつつあるアジャイル開発やDevOpsに、セキュリティ対策を加える一助となれば幸いです。

ラックのシステムセキュリティデザインサービスでは、アプリケーション開発工程の全て、もしくは各工程単独での業務支援サービスのご提供が可能です。ご興味がございましたら、ぜひお問い合わせください。