個人の日常生活の見直しによるセキュリティ改善とは異なり、企業レベルのセキュリティとなるとその責任も大きなものになります。いわゆる「会社のセキュリティ部門」と呼ばれる人たちがいるならまだしも、「セキュリティの専門ではないけど対策しろと言われている......」といった人たちはどのようにすればよいのでしょうか。責任だけ負わされ、実際にインシデント(セキュリティ対策を突破されたあとの実被害)が発生してからアタフタすることのないよう、責任の所在やその対策に至るまでの理由をはっきりさせておくべきです。本来「負わされるべき」なんていう言い方はするべきではありませんが、それでも企業の規模に問わず、BtoBの取引において責任の所在は重要な要素です。基本的に個人情報漏洩においては、その責任はその個人情報を保持している企業にあるとされますが、有名なSQLインジェクション事件の例もあります。SQLインジェクション対策を怠った開発会社に賠償命令この事件は、とあるインテリア会社のサイト開発を請け負った開発会社が、SQLインジェクション対策を怠っていたがゆえに発生した個人情報漏洩事件です。クレジットカード情報の流出が発見されたため、インテリア会社から開発会社への損害賠償請求が行われました。結果として、インテリア会社は勝訴したものの、開発会社と発注側の企業とのセキュリティへの温度感のようなものが浮き彫りになる結果となりました。開発会社に責任があるべき当然ながらクレジットカード情報を登録して買い物をしているユーザーに対しては、それを提供している上記例でいうところのインテリア会社が責任を持つべきです。第三者から提供されたシステムによって被害を被った場合は提供会社もまた被害者になりえます。開発会社はSQLインジェクションという有名な脅威に対して、コストがかかるという観点から対策を施さなかったことは過失とみなされました。経済産業省やIPAの指針からもSQLインジェクションは当然対策をなされる脅威であることはソフトウェア開発会社であれば知っていてしかるべき、という結論とされています。発注側も発注側で本来オンラインストア本体のあるサーバーにユーザーの個人情報を保持すべきではない、という状況をコストアップを避けるために対策せずに放置したという事実もあります。これによって提供会社もまた、責任の一部を負うべき状態です。セキュリティ対策を考慮するタイミングWebサイトやオンラインサービスを始めるにあたって、外部に発注をかけるような場合は「要件定義からセキュリティ対策を始める」べきです。これが意味するところとして、当然発注側にもセキュリティに対する知見も必要になりますし、逆に言えばこの機会にセキュリティへの意識を社内へ浸透させると良いでしょう。開発会社と相談しながら社内のセキュリティ指針をドキュメント化すれば次回からよりスムーズに発注できるようにもなります。予算とスケジュールで真っ先に狙われるセキュリティこれは本当に悲しいことなのですが、セキュリティ予算というのがかなり早い段階から削るものとして狙われがちです。最近になってようやく、大事な要件として扱われることも多くなり始めましたが、それでもセキュリティ対策のための時間とお金は削られがちなのが現状です。発注する側の企業からすれば「ユーザーもそこまで多くないうちにお金かけるより、早くリリースして収益化が確定してからセキュリティ対策すればいいんじゃない?」といった意識の方が多いように感じます。正直なところ、そういう考え方もありではあるのですが、それはユーザーの個人情報を一つも保持せず、被害を受けるのが自分自身だけ、という状態ならそれでもOKです。エンドユーザーに迷惑をかける可能性を考えると、その被害レベルはユーザー数が想定できないために「被害×無限大」となります。ECサイトやユーザーにログインを促したりフォームに入力をさせるようなサービスをリリース予定であれば、セキュリティに関してはリリース前にシビアな会議を開くことをオススメします。品質管理とテスティングWebサービスやアプリケーションにおける品質管理とは、UIやUXから見てプロダクトとして優れているか、ではありません。食品や医薬品が国家の厳しい品質レベルをくぐり抜けて一般消費者に届くように、「一般消費者に提供できる一定のラインを越えているか」を意味します。ソフトウェアやアプリケーションの品質管理は、国ですべてを制御できない一方で、組織レベルの品質管理能力が問われやすい要素です。単体テストや連結テストなど、多くのテスティングを経て品質管理をしているのがソフトウェア業界の常ですが、そこにUI・UXベースのテストも含めることを忘れてはいけません。クロスサイトスクリプティングやSQLインジェクションは、ユニットテストだけでは見つからない場合も多いです。社内規定や指針の存在とマネジメント部門のコミット実際に「これから社内セキュリティ改革を始める!」という場合や「今までなぁなぁに済ましていたけどこれからしっかりやっていこう!」という場合には、社内規定を作成することをオススメしています。社内的に「このレベル以下はリリースしないよ」というものです。これをはじめから作って進める、というのではなく、プロダクトの開発と同時に、あるいはサービスの運営を継続しながら「この部分ってセキュリティ的にOKなの?」と常に疑問を持ち続けながらつくっていくことが大切です。最近ではhttpではなくhttpsでないとまずいっぽいけど、うちのサービスはまだhttpっぽい......これってNGじゃない?のような流れがあれば、社内規定に「サイトはすべてhttps(SSL)で運営されなくてはならない」という規定をつくることができます。これらの指針のベースにIPAの出す安全なウェブサイトの作り方がありますので、参考にすると良いでしょう。これらのセキュリティに対する活動を応援してくれるマネジメント層が必要であることも付け加えておきたい部分です。マネジメント層が「我が社のセキュリティがヤバいっすよ!」という言葉に反応してくれないようなら、転職も考えたほうが良いです。セキュリティ意識に敏感な上長であれば、すぐにあなたにそのスケジュールを与えてくれるでしょう。動き始めるなら今すぐに!何はともあれ、セキュリティ対策は一日でも早く進めることが大切です。仮にまだリリースされていないサービスであろうと、その要件定義にセキュリティに対するスケジュールを組んでおくべきです。ソフトウェア開発者だけでなく、ユーザーデバッグとして一般的なITリテラシーの人にテストしてもらうことで見つかるバグもあります。確実に、組織としてのセキュリティ指針を作り上げていくことで高品質なサービスを継続的にリリースできる組織になっていくことでしょう。Co.,Ltd開発部の合同公式ブログ。代表がITエンジニア出身のデジタルノマド→日本とベトナム・ホーチミンでIT企業設立。海外デジタルノマドやエンジニアのリモートワーク、プログラミング、オフショア開発やミニラボ情報などをまとめていきます。Co.,Ltd開発部の合同公式ブログ。代表がITエンジニア出身のデジタルノマド→日本とベトナム・ホーチミンでIT企業設立。海外デジタルノマドやエンジニアのリモートワーク、プログラミング、オフショア開発やミニラボ情報などをまとめていきます。