コラム
「セキュリティ・バイ・デザイン」というフレーズをご存じでしょうか？
弊社はこのサイト上でも営業用のプレゼンテーションでもLexicaの特徴、あるいは設計ポリシーのひとつとしてこのフレーズを掲げています。
ECは本質的に個人情報の保護とユーザビリティを高度にバランスさせなければなりません。ですので、このセキュリティ・バイ・デザインという考え方はECにとってはとりわけ重要であり、大きな価値を持っています。
とは言え、このアイデアはそもそも開発者向けのものということもあり、ユーザーとしてはどうもピンと来ない、セキュリティとデザインにそんなに深い関係があるの？という方もいらっしゃるかも知れません。
ですので、そんな皆さまのためにこの記事では、IPAの入門資料を紹介しつつ、さらに簡単な解説を少しだけさせていただきます。
セキュリティ・バイ・デザインについて、IPAの超入門書
IPA（独立行政法人 情報処理推進機構）は、国家試験である情報処理技術者試験を主管している公的な組織です。こちらで公開されている資料が以下です。
IPA セキュリティ・バイ・デザイン「システム開発のセキュリティ向上0.0」
上記リンクの画面内からPDFの読み物が取得できます。細かい参考資料に入り込まずに本編のみ流し読みするならば小一時間もかからないボリュームですから、お手すきの際に是非ご一読いただくのがよろしいかと思われます。
行政系機関の文書ならではの堅さと、それを自覚して無理に親しみやすくしようとした結果のちぐはぐさや冗長さなど気になる点はありますが、読みやすくしようという努力の感じられる作品ですので、ECのシステム導入に関わる立場にあればおおいに得るものがある読み物です。
全3章あり、第2章がメインコンテンツであるアンチパターン集ですが、時間のない方は第1章が特に重要ですのでしっかり読み、第2章は解説を流し読みし（無理に時流に乗ろうと足掻いた結果にしか見えない「生成AIに聞いてみた！」のコーナーなどは読まなくていいと思います、個人的には）、第3章は謝辞なのでもう”そっ閉じ”しても良いかも知れません。
※ご注意 べつにケチをつけてはいません。時間のないビジネスパーソンのための助言を述べているだけです。特に第1章はよいサマリーになっていると思いますのでオススメします！
さらに時間のない人向けの超概要
とは言え、弊社のウェブサイトを閲覧しているユーザーは漏れなく多忙なビジネスパーソンであり、もしかすると（まだLexicaを導入していない）ECの運用担当者であり日々の業務に忙殺されているのではと思いますので、IPAの資料をゆっくり読む時間もないかも知れませんし、読むにしても最初にツボを押さえておいた方が読みやすいというものです。
ですのでここからは、筆者が上記の資料に記載の内容をもとに、ユーザー向けの視点でごくごく簡潔に、セキュリティ・バイ・デザインについてまとめます。
「デザイン」は設計のことです
まず念のためになりますが、ここで言う「デザイン」は絵的なものではなく、「設計」という意味になります。システム、プログラムをどう設計するか？ということであり、画面の見た目やグラフィックのことではありません（それらのUIの見た目ももちろん設計の要素のひとつではありますが、ここでは主要ではありません）。
問題の修正は後になるほど高いコストがかかる
前述の資料によれば、「テスト段階で発見された欠陥の修正コストは、設計段階の場合の 15 倍」であるとされています。もちろん、これは特定の数え方におけるひとつの捉え方に過ぎませんが、設計時点での問題が放置され修正が後になるほど、修正コストが跳ね上がること自体に疑いの余地はありません。
そして、この問題が致命的なセキュリティ上の欠陥であって、稼働時にリスクが顕在化するまで放置された場合には、コストが多くて残念だというようなレベルの問題では済まされず、巨額の損失や深刻な信用失墜によりビジネスの継続自体が不可能となる場合があります。そうした場合にはもはや、1.5倍なのか15倍なのかといったことさえ些末と言えるような、取返しのつかない事態になる可能性もあるということが重要なポイントです。
ECにおけるセキュリティは、コスト管理や業務効率の問題ではなく、ビジネスの継続性に関わる問題であり、経営の問題であるという認識をしなければなりません。
セキュリティ・バイ・デザインを一言で言えば
「セキュリティ・バイ・デザインとは、システムやソフトウェアの要件定義・設計の段階からセキュリティを組み込むアプローチ」とのことです。
逆に、「バイ・デザインではないセキュリティ」は何か？ということを考えた方が具体的にイメージしやすいかも知れません。それはつまり、業務機能要件や性能要件など「やりたいこと」ばかりに注目してシステムを作りあげた後に、「やりたくもないがやらなければいけないこと」としてセキュリティ診断を受け、指摘事項にパッチをするようなセキュリティ実装であって、言い換えれば、これまで多くのシステム構築の現場で普通に行われていて、いまでもわりと普通に採用されているかも知れないアプローチによるものです。
要求分析時点からのセキュリティ対策
開発初期からセキュリティを考慮し、設計レベルで対策を行うということがセキュリティ・バイ・デザインという手法です。
前述のIPAの資料では例えば、要件定義フェーズにおいてセキュリティ要件定義を行い、設計フェーズにおいてセキュリティ設計を行い、コーディング（実装）段階においてセキュリティ実装+を、それぞれセキュリティ対策として行うということを示しています。
こうして開発の初期、広い意味での設計段階からセキュリティ工程を組み込むことで、事後からの対策に比べて短期間・低コスト・確実にセキュリティを実現するという考え方がセキュリティ・バイ・デザインです。
なお、ここでは割愛しましたが、前提として顧客（システム発注側）にはリスク分析やRFPでのセキュリティへの言及などのタスクが必要です。また、これらの工程が、開発後期における脆弱性診断などを不要とするものではありません。
しかし、ERSの解釈は少しだけ異なります。
ここからはIPAの解説を離れERSとしての考えをお話します。IPAの資料による説明は一般的に妥当なものと思いますが、我々はさらにもう少し考えを先へ進めています。
例えば、「XSS脆弱性を埋め込むことがないようにユーザー入力値を画面に出力する際に適切にエスケープ処理する」、という「セキュリティ要件」があるとします。これは、機能要件と切り離して「セキュリティ要件」として個別に考えられるべきものでしょうか？
※ XSSとは、Cross Site Scriptingというもので、あらぬところにHTML（主にJavaScriptを含むもの）を入力してシステムの誤作動を誘い、不正アクセスの糸口を作ろうとする行為です。
XSS脆弱性がある状態では、そもそもユーザーの入力値として、例えば「"><script>alert('Hello')</script>」という住所を表示しようとした場合、この文字列は表示されずに画面に”Hello"というスクリプトダイアログが表示されます。そんな住所があるわけないだろ！という問題はさておき、ユーザーはそれを住所として入力したわけです。彼の心の裡には別の悪意の目的があったにせよ、形式的には住所として入力していて、それをシステムが拒否していないのであれば、次にシステムがするべきことは、「住所をそのまま表示する」という普通の機能要件を満たすことだけです。つまり、スクリプトを動作させることなく、"><script>alert('Hello')</script>という文字列を住所欄に普通に表示すればよいわけです。この一連の対応に、「セキュリティ」という概念は必ずしも必要ではありません。
他にも例えば、セキュリティ上の問題にはしばしば「認証の欠如」などと言い表されるものもありますが、そもそもECのように個人が個人情報を預けてアクセスするシステムにおいて認証機能が必要であるということは単なる機能要件に過ぎません。
つまり、セキュリティ対策のためのセキュリティ要件定義やセキュリティ設計が必要であるという状況は、往々にしてそもそも機能要件の見定めが不十分であるということを意味しています。
なぜ、必要な機能要件を見落としてしまうのか。そして、その見落としを補うために「セキュリティ要件定義」をしなければならないのか。短く言ってしまえば、それは知識が不足しているからです。
セキュリティ要件定義という工程を考えたとしても、それをセキュリティに関する専門知識のないエンジニアが行ったのでは期待する効果は得られません。そして逆に、セキュリティの専門家でもあるエンジニアが要件定義を行うのであれば、セキュリティ要件は自ずと機能要件に統合されるはずです。つまり、必要なものは工程ではなく人材です。工程に「セキュリティ」という形容詞をつけることは、必要な人材を強調する効果はあるかも知れませんが、対策の本質ではありません。
つまり最初に必要なことは、工程を変えることではなく、セキュリティの専門家をプロジェクトに配備することです。社内にそうした人物がいないのであれば、外部のリソースを活用しても良いでしょう。専門家とはどういう人なのか？ということで迷ってしまうならば、国家資格である情報処理安全確保支援士（登録セキュリティスペシャリスト、RISS）の保有者を探してみるのも良いかもしれません。有資格者を以下のサイトで検索もできます。
その上で、そうした専門家を効率よく活用するために、「セキュリティ要件定義」工程を機能要件定義から切り離すということは、あり得る選択肢ではないかと思います。しかし、まずは専門家が必要であるということをよく理解しなければなりません。
さいごに
ところで、ERSにはRISSの有資格者が複数在籍しており、Lexicaの開発や導入に携わっています。また、その他のエンジニアの多くは国家試験であるセキュリティマネジメント試験の合格者です。
つまり、Lexicaを導入するということは即ち、セキュリティの専門家をプロジェクトの最上流から参画させるということを意味すると言えます。Lexicaの製品そのもの、フレームワーク機能にセキュリティ実装が組み込まれていることは勿論ですが、ERSのエンジニアが要件定義を行う場合、そこには常にセキュリティの専門家としての視点があります。
それが我々としてのセキュリティ・バイ・デザインの実現方法です。唯一の方法であるとは思いませんが、効率の良い方法であると思っています。
ECの導入をしようと思うがセキュリティ・バイ・デザインと言われても具体的にどうすれば良いやら・・・とお困りの皆様は、ぜひLexicaをご検討ください。