3分で分かるセキュアプログラミング

セキュアプログラミングと聞くと、「プログラマの話」と思われるかもしれません。
プログラミングを行うプログラマが脆弱性を作り込まないコーディングをすることが大切なことは言うまでもありませんが、実際のところ、それだけではセキュアなサービス開発は難しいのです。
セキュアなサービス開発のためには、各工程で抑えるべきポイントがあるのです。

3分でわかる3つのポイント

3min_point

ポイント1

~要件定義の段階で、セキュリティ機能(要件)とセキュリティ・バグは分けて考える~

「セキュリティ機能」とは、積極的に安全性を強化する機能のことです。認証方法等がこれにあたります。「セキュリティ・バグ」とはSQLインジェクションやクロスサイト・スクリプティング(XSS)などの脆弱性のことです。
セキュアなサービス開発のためには、認証方法などのセキュリティ要件は仕様として定義し、そのあと粛々と実装するSQLインジェクションなどのセキュリティ・バグへの対処法を明確にすることが重要です。
バグをなくすことが当たり前であるように、脆弱性をなくすことも当たり前です。一方、セキュリティ機能を要件として盛り込むか否かは、コストとの兼ね合いで決定します。

ポイント2

~開発標準の整備とメンバーの教育でチーム力をアップする~

基本設計の段階で、方式設計において開発標準やテスト方式を整備しておきます。セキュリティ機能については、通常の機能要件と同じように粛々と設計・開発・テストを行います。
セキュリティ・バグについては、プログラミング可能なレベルに具体化された開発標準を整備します。併せてテスト方式も決定しておきます。これにより、メンバーのセキュリティレベルがばらばらであっても、開発標準の通りにコーディングすれば脆弱性を作り込むことがなくなります。
開発の段階では、メンバーに開発標準(コーディング規約)の遵守を徹底させます。開発標準が整備されていても、メンバーがその通りにコーディングしなくては意味がないからです。そのために、開発標準をメンバーに学習してもらい、規約を破ると本当に危険だと認識してもらうことが重要です。

ポイント3

~コスト要因となるレビューとテストを計画的に~

開発の段階で実施するコード・レビューの方針を決めておきます。誰がどの範囲をチェックするのかを明確にし、レビューできる担当者のリソースを確保します。
また、テストの段階で実施する脆弱性検査の方針を決めます。セキュリティ機能もセキュリティ・バグも、最終的にはテストにより要件を満たすことを確認する必要があります。内部検査を基本にしますが、担当できるメンバーがいない、サービス内容からより精度の高いテストが必要等、状況に応じて外部の専門ベンダーに依頼することも検討します。
ポイント1、ポイント2が十分でないと、テスト→修正の繰り返しに時間がかかりコストが増大してしまいます。

EGセキュアソリューションズはポイント1~3まで、
すべてをサポートするコンサルティングや教育サービスをご提供します。

サービス案内ページへ