システムライフサイクルプロセスにおけるセキュリティ

こんにちは。
夏が来るたび、日本の暑さに戸惑っています。
金融IT本部でお仕事をさせていただいております、新卒入社3年目の青井です。

今回は、情報処理安全確保支援士のオンライン研修（２年目）で学んだ中から、システムライフサイクルプロセスにおけるセキュリティについて少しお話ししようと思います。
セキュリティのフレームワークやガイドラインについて実業務で少し考える機会があったので、紹介します。
セキュリティに興味がある若手SE（興味なくてもトレンドとしておさえるべき？？）、電通総研に興味がある学生（実際どんな仕事してるの？）向けに、できるだけライトに書いているので、「ふーん。」くらいで読み流していただけると幸いです。

1. 情報処理安全確保支援士とは

初めに先ほど出てきた情報処理安全確保支援士についてさらっと説明します。
情報処理安全確保支援士は、サイバーセキュリティ対策を推進する人材の国家資格です。
いわゆるセキュリティの専門家です。登録セキスぺとも呼ばれています。
3年毎に更新があり、毎年1回のオンライン研修と3年間で1度の実践講習の計4回の受講が必要です。
電通総研では、情報処理安全確保支援士に関しての受験費用・研修受講費を全額負担してくれるので、費用面の負担なく資格の取得・保有が実現できます。
（結構高いんです。ありがたい。。。）

参考：情報処理安全確保支援士（登録セキスぺ）

2. システムライフサイクルプロセスにおけるセキュリティとは

昨今の情報システムは、複雑化・高度化に伴い、適切なセキュリティ対策が不可欠となっています。システムライフサイクルプロセスとは、情報システムの企画・要件定義から運用、保守、廃棄に至るまでの一連の流れを指します。このプロセスにおいて、セキュリティを適切に組み込むことで、情報システムの安全性と信頼性を確保することができます。
（言葉では簡単に言えるものの難しいんですよね、、、）

セキュリティは、システムライフサイクルのあらゆる段階で考慮される必要があります。企画段階では、セキュリティ要件の明確化や、リスク分析など、セキュリティ対策の検討が重要です。設計・開発段階では、セキュリティ機能の組み込みや、脆弱性の排除が求められます。運用・保守段階では、セキュリティパッチの適用や、監視・分析による脅威の早期発見、廃棄段階では確実・完全な情報の抹消など、継続的なセキュリティ対策が不可欠です。

このように、システムライフサイクルプロセスにおいて、適切なセキュリティ対策を講じることで、DevSecOpsを意識したセキュアなシステム運用への移行を実現することができます。

DevSecOpsとは、開発(Development)、セキュリティ(Security)、運用(Operation)の3つの領域を統合的に管理・運用していくアプローチのことを指します。従来は、開発とセキュリティ、運用がサイロ化（分離？孤立？のイメージ）されていましたが、DevSecOpsではこれらの領域を並行して進めることで、開発サイクルの早期からセキュリティを組み込み、セキュアで高品質なシステム構築を目指します。（とは言ってもこれがなかなか難しい。。。）

気になる方は、DevOpsとの違い等も学べるので是非色々調べてみてください！

3. ポイントは企画・要件定義段階におけるセキュリティ対策

情報システムのライフサイクル全般を通じて、セキュリティを適切なレベルで維持するためには、企画・要件定義段階からセキュリティ要件を定義することが重要です。
システム開発をする際、機能要件で要件定義に落ちていないものは、通常その後の設計・製造工程で拾われません。
非機能要件のセキュリティも同じように、要件として定義できていないと、適切なセキュリティ対策がその後の工程に反映されません。セキュリティ要件の曖昧さや過不足は、過剰なセキュリティ対策によるコスト増や後工程での手戻り、運用後のセキュリティインシデントの発生につながります。

企画・要件定義段階でのセキュリティについての検討は、高品質で安全なシステムの構築に必要不可欠です。
昨今のシステムセキュリティに対する関心の高まりに伴い、その重要度が機能要件と同レベルになってきていると感じています。

4. 社内向け支援システム開発で実際に検討してみる

ありがたいことに、社内向けの小規模システムのセキュリティについて少し考える機会をいただきました。
まずは一人でセキュリティ要件について考えてみました。通信・暗号化方式やアクセス制限、Webセキュリティ関連などなど。
が、、、全然思いつかない。
ここで、IPAの非機能要件グレードのセキュリティを確認してみたところ中項目だけで11項目もありました。
前提条件・制約条件からインシデント発生時の対応・復旧に至るまで、数多くの考慮事項があります。
正直、非機能要件と言いながら、考慮する事項が機能要件並みのカロリーがあるなぁと、、、

特にセキュリティリスク管理やセキュリティインデント対応/復旧などの運用後の想像が足りないなと実感。
試験ではイメージできてもいざ、実務でとなると試験以上に難しく自分の実力不足に打ちひしがれました。
（試験では、選択肢もあり、状況も整理されている）
実際の現場では、より複雑な状況（予算や期間など様々な条件）に直面するため、より高度な対応力が必要であると感じました。圧倒的な経験＆スキル不足によるセキュリティ要件のあいまい・過不足が顕在化してしまいましたね。。。
実際に『政府機関等の情報セキュリティ対策のための統一基準（令和5年度版）』やIPAの『システム構築の上流工程強化（非機能要求グレード）』をもとに観点等を洗い出し、たたき台を作成してみます。
特に網羅性の観点で効果が見られ、経験・スキルがない私自身でもたたき台程度のものは作成することができました。

システムライフサイクルプロセスにおいては、セキュリティに関する多くの考慮事項が存在します。
機能要件だけでも大変なのに、非機能要件にまで頭を悩ませられます。ツラい、、、笑

5. 実際の検討からの学び

研修の受講から実際の検討を通して、思考プロセスにおけるガイドラインやフレームワーク活用の有効性を学びました。
普段、システム開発の中でReactやSpring等のフレームワークや、インフラ選定でAWS等のクラウド基盤を使用するなど、目に見えるテクニカルな部分にスポットライトを当てることは容易でした。そうすることで、本来時間をかけるべき新たなサービスの創出等、コアな業務に注力できるというメリットは実務を通して認識できていました。
しかし、セキュリティの企画・要件定義などの思考プロセスにおいてガイドライン等を適用するという経験が今まで無く、そのような選択肢が頭にありませんでした。

このように経験やスキルの差を埋めてくれるのは、ガイドラインやフレームワークであることを身を持って実感できました。

6. まとめ

結局何を伝えたかったのかというと、要件などの思考プロセスにもガイドラインやフレームワークを活用すると良いということです。
冒頭でも述べましたが、DevOpsからDecSecOpsへとセキュリティに対する注目は日々高まっています。
これまで非機能要件として認識されていましたが、その重要度とウエイトからもセキュリティが機能要件として認識される時代が来るのではないのかな（すでに来ている？？）と思っています。

電通総研は、若手でも色々な機会（チャンス）を与えていただける環境です。自分がこれまで経験したことがない仕事はそれなりのストレスがかかりますが、達成と同時にストレス以上の成長を感じることができます！
今後も機会があれば、机上では獲得でき得ない経験をどんどん積み上げていきたいです。

ここまで読んでいただきありがとうございました。
これらを読んで、セキュリティと関連するガイドライン、フレームワーク（あと電通総研。。。）に少しでも興味を持っていただけると幸いです。