開発フェーズにおけるセキュリティ要件の課題と解決アプローチ

システム開発の初期段階から、セキュリティ対策に取り組むことは極めて重要です。なぜなら、セキュリティ対策が不十分であると開発が進むなかで取り返しのつかない問題が発生し、組織や顧客の信頼を損なうリスクが高まります。

そのため、多くの企業では自社標準のセキュリティ要件を定め、対策の徹底を図っています。しかし、システムの多様化・複雑化、組織のサイロ化などの影響により、形だけの運用にとどまるケースも少なくありません。

本記事では、開発フェーズにおけるセキュリティ対策の現状と課題を整理し、「LAC Karasu（ラックカラス）」というツールを活用した実践的な解決手法について解説します。

開発フェーズにおけるセキュリティ対策の重要性

近年、多くの企業において、本番環境で稼働しサービスを提供するシステムへのセキュリティ対策が進んでいます。本番環境でのセキュリティインシデントが経営に与えるリスクの大きさが認識され、経営課題として注目されているためです。特に、システムに対するセキュリティ監視や診断、脆弱性対応に注力し、セキュリティ対策の体制が整いつつあります。

本番環境のセキュリティ対策が整い始めた今、次に注目すべきは開発フェーズのセキュリティです。このフェーズでは、悪意のある攻撃者が不正にセキュリティ問題を生じさせるのではなく、正当な開発手順を踏むなかで、開発者が意図せずにセキュリティ上の問題を組み込んでしまい、そのまま本番環境に影響を与えるリスクがあります。

極端な例ですが、意図しないポートが公開されてしまう、機密情報へのアクセス制限が解除されてしまう、あるいは外部サイトのモジュールを直接読み込んでしまうといったケースが発生すると、せっかくの本番環境でのセキュリティ対策が台無しになりかねません。

開発フェーズでのセキュリティを徹底しなければ、本番環境への影響は避けられないでしょう。

開発フェーズにおけるセキュリティ要件の課題

多くの企業は自社標準としてセキュリティ要件を明確に定め、チェックリストを運用することで、開発段階からセキュリティを確保する取り組みを進めています。

具体的には、企画段階が終了した後の開発フェーズ開始時にセキュリティチームはセキュリティ要件を提示し、開発チームに計画へ組み込んでもらいます。その後、機能テストが終了次第、セキュリティ診断が実施され、問題があれば修正が行われます。リリース前にリリース審査としてセキュリティ要件を満たしているかどうかをチェックリストの回答結果と証跡に基づいて確認します。

ただし、こうしたやり方には次のような課題が考えられます。

セキュリティ要件が抽象的で具体的な対応が不明確

すべてのシステムに適用可能な自社標準のセキュリティ要件を作成するため、必然的に要件内容が抽象的になりがちです。

Web、スマホ、API、クラウド、コンテナ、OSSなど、多様化・複雑化が進むシステムを対象とする上で、これは避けられない側面です。しかしその結果、提示を受けた開発チームにとって具体的に何を実施すべきかが不明確になり、システムに応じた適切な対策が講じられない場合があります。

セキュリティ要件提示から確認までの期間が長すぎる

セキュリティ要件の提示を受けてから、セキュリティ要件を満たしているか確認するためのセキュリティ診断やリリース審査までの間が長くなってしまうことが多く、その結果、開発チームのセキュリティ意識が徐々に薄れてしまいます。これにより、必要なセキュリティ対策が忘れ去られてしまったり、後回しにされて実施されなかったりすることがあります。

また、要件に対する認識の齟齬が解消されないまま放置されることで、結果として誤った対策が実施されるリスクも高まります。

セキュリティ要件の確認がリリース前に集中する

セキュリティ要件の確認がリリース直前に集中してしまうことで、いくつかの問題が発生します。

まず、最後にまとめて対応しなければならないセキュリティ項目が多くなるため、対応負荷が非常に高くなります。さらに、リリース期限が決まっているため、対応に十分な余裕が持てない状況も生まれます。その結果、リリースを優先するあまり、セキュリティの問題に対して暫定対応が行われたり、突貫作業での対処が増えたりすることがあります。

また、対応優先度が下がり、問題が後回しにされたり、最悪の場合は対応されないままリリースされたりするケースもあります。一方、セキュリティ対応を優先すると、リリース自体が遅れ、ユーザーに影響を与えるリスクもあります。

このように、リリース前の集中による負荷は、セキュリティとリリーススケジュールのいずれにも悪影響を及ぼし、結果的にシステム全体の安定性や信頼性が損なわれる懸念が生じます。

セキュリティ要件を満たしてもらうための3つのアプローチ

これらの課題を解決するには、以下の3つのアプローチが効果的です。

1. 小さく少しずつ

セキュリティ要件の対応と確認をリリース直前にまとめて行うのではなく、実施すべきタイミングやフェーズごとに小さく少しずつ進めていくことで、さまざまなメリットが得られます。

まず、対応負荷が適切に分散され、無理のない現実的な対応が可能になります。また、段階ごとに細かく確認が入ることで、認識の齟齬が発生しても早期に修正できるため、対応の精度が向上します。

さらに、セキュリティ対応が継続的に行われるため、対策が忘れられたり後回しにされたりするリスクも軽減されます。これにより、対応に余裕を持つことができ、品質を保ちながら適切なセキュリティ対策を講じることが可能となります。

2. システム特性と開発情報に応じたセキュリティ要件提示

多くのセキュリティ要件のなかから、今回の開発案件に適用される要件を抽出することが重要です。システムのアーキテクチャや保有する情報に基づいて、特定のセキュリティ要件を定めることで、実際に求められる要件に絞り込めます。

このようにシステムの特性に応じたセキュリティ要件を提示することで、開発チームにとっても、何を優先的に対応すべきかが明確になり、効率的にセキュリティ対策を進めることが可能となります。

3. ビジネスインパクトを考慮したセキュリティ対策

抽象的なセキュリティ要件を具体的な対策に落とし込むには、ビジネスインパクトを考慮することが有効です。

具体的には、経済的・社会的な影響や利用者・サプライチェーンへの影響といった要素を踏まえ、対応方法をより具体的に検討します。これにより、抽象的な要件が実際の対策に結びつきやすくなり、ビジネスの重要度に応じた適切なセキュリティ対策が推進されます。

こうしたアプローチにより、開発チームにとってはセキュリティが開発プロセスに統合される一歩となり、セキュリティチームにとっても開発段階でのセキュリティリスクを可視化することが可能になります。さらに、この取り組みを通じて、開発チームとセキュリティチームの連携が一層強化されていくでしょう。

LAC Karasu（ラックカラス）：課題解決のためのツール

ラックではセキュリティ要件を満たしてもらうための3つのアプローチを実現する「LAC Karasu（ラックカラス）」を2024年9月に公開しました。

このツールにより、システムの特性やビジネスインパクトに応じて、必要なタイミングで最適なセキュリティ対策を実施できます。また、開発の初期段階からセキュリティの取り組み状況を把握することが可能です。詳細は、下記のLAC Karasuの製品資料をご覧ください。

現在無料でLAC Karasuを体験いただけるアーリーアクセスプログラムを実施しています。ご興味ございましたら是非ご参加ください。

さいごに

開発フェーズにおけるセキュリティの重要性は高まっており、プロセス全体にセキュリティを組み込むことが不可欠です。

「LAC Karasu」のようなツールを活用することで、開発チームとセキュリティチームの連携が強化され、リリース直前の大きな修正を防ぎながらセキュアなシステムを構築できます。これにより、セキュリティをプロセスの一部として自然に組み込み、確実なセキュリティ体制を整えたリリースが可能となるでしょう。