はじめに
前回の記事 の続きとなります。
概要など前置きについてはそちらをご参照ください。
単元2 システムライフサイクルプロセスとセキュリティ対策
近年、情報システムは大規模かつ複雑になっていることを前提に、システムライフサイクル全体やサプライチェーンも網羅的にセキュリティ対策に取り組む必要があります。安確士には要件定義から構築、運用に移行するまでセキュリティ支援することを期待している、としています。
1章システムライフサイクルとセキュリティの対応 にて、システムライフサイクルの各プロセスについて、
- 企画フェーズでは調達やシステムの仕様など
- 設計フェーズではセキュリティ要件から製品やサービスの選定・設定検討や、システムやアーキテクチャがセキュアであるか評価するなど
- 開発・テストフェーズではセキュリティ機能の設計及びテストの内容・実装方法をレビューすることなど
- 運用フェーズでは運用の終了までを見据えた運用保守に関する文書のレビューや担当者の教育など
- その他、開発から運用終了まで開発にかかわるセキュリティ対策や外部委託のリスク対策など
を考慮することとしています。この単元では「企画・要件定義」「調達・構築」にフォーカスして学習します。
セキュリティ要件の設定について、事業や情報資産に対するリスクアセスメントの結果から要件策定することや、既存のガイドライン等にある管理策を自組織に合わせた策定が多いとのこと。
セキュリティ要件を策定するにあたって曖昧さや過不足があると、開発時の手戻りや運用中のセキュリティインシデントが発生する可能性、また過剰にセキュリティ対策をすることによるコスト増加の可能性に繋がります。策定時に過不足が無いか、網羅的であるかなどの確認が必要です。
また、運用期間が長くなってもセキュリティを確保できるように要件定義をすることが重要だと説いており、例としてTLS1.0, 1.1のサポート終了を挙げ利用している暗号アルゴリズムが安全でなくなることも起こりうるとしています。実際に利用する暗号技術の選定については、CRYPTREC推奨暗号が参考になるとのこと。
3章では機器・ソフトウェアのサプライチェーンリスクについて触れており、
- セキュリティ管理が杜撰なサプライチェーン上の事業者による情報漏洩
- 委託先に埋め込まれた不正プログラムによる情報窃取
- 利用しているOSS等の脆弱性に対するゼロデイ攻撃
などをリスクとして挙げています。全てのサプライチェーンを管理することは困難としており、それを前提に調達段階でセキュリティ要件を策定、委託先との協働が必要だとしています。
開発環境のセキュリティについて、ソースはもちろん設計情報やテスト手順についても情報資産であり、リスクアセスメントをし対策する必要があります。具体的な例として、リテラシーの低い開発者がソースコードをクラウドサービスに公開することで起きる流出などを想定して教育を行う、といった対策です。
なお利用しているOSSや製品のバージョン等の構成情報は、運用開始後に脆弱性が発見されたなどの際、該当するバージョンを使用しているかの確認から始める必要があり対応が遅れる原因になりうるとして、開発と運用で連携して管理することが望ましいとのこと。
その上で、OSSや製品にアップデートが提供された際適用するかの判断基準を定めておくと良いとしています。
システム開発手法をセキュリティの観点から比較しており、従来多く採用されていたウォーターフォールと近年増えてきたアジャイル開発を例に挙げています。
セキュリティの観点からみたアジャイル開発はウォーターフォール型と比較して、
- イテレーションごとのセキュリティ検討が実施できること
- リリースサイクルを短くすることで迅速にセキュリティ対応バージョンをリリースできること
が利点として挙げられていました。
反面、アジャイル開発においてはプロダクトオーナーの方針によってセキュリティの優先順位が低く捉えられていると、発現したリスクによっては顧客の価値や得た利益を損なうことにも繋がる。リスクそのものの発生率や起きた時の損害も加味して適切に優先順位設定できるようプロダクトオーナーに理解させることも安確士の役割としています。
単元末尾の理解度テストの問題は、前単元のものと比べて比較的易しく感じる内容が出題されました。問題内容について触れることはしませんが、誤っているものや適切なものを択一するもので、表現に注目すれば運転免許試験や基本情報技術者試験に似通った難易度と感じました。結果としてはこの単元は1回でクリアとなりました。
次の単元に続きます。