ITシステム開発者必修のセキュリティ概念 Top 10です。ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。順序はその基礎知識性、重要性、分かり易さで付けています。

では開発者必修のセキュリティ概念 Top 10です。

※ 長くなったので短い版を作りました。ロング版はこちら

1. ゼロトラスト

ゼロトラスト（Zero Trust）とは何も信頼しないことです。言い換えると、検証／保証したモノ以外は信頼しない、です。セキュリティはコアとなる信頼できるモノから、リスクの検証／許容で信頼可能な範囲を広げていきます。

2. 信頼境界線

信頼境界線（Trust Boundary）は信頼可能な範囲の境界です。”ゼロトラスト”で信頼できる範囲を広げても、様々な制約から必ず「ここが限界」という境界ができます。

信頼境界線は少なくとも次の4つのコンテクストを区別する必要があります。

• 物理 – 場所やハードウェア、人
• ネットワーク – 通信
• ソフトウェア – プログラム
• システム – 上記3つのコンテクストをまとめて”システム”単位で記述したもの。

ソフトウェアコンテクストの信頼境界線の基本は「同一プロセスまたはスレッドを越えることはできない」です。セキュリティ設計では上記4つのコンテクストで信頼境界を確定する必要があります。

3. ホワイトリスト優先

セキュリティ対策において、何かを検証する時は必ずホワイトリスト型の検証を優先します。

• ホワイトリスト ｰ 良いモノを定義し、良いモノだけを受け入れる
• ブラックリスト ｰ 悪いモノを定義し、悪いモノを除いて受け入れる

大抵の場合、「全ての悪いモノを漏れ無く定義」することは「良いモノを定義」するより困難です。セキュリティ対策ではホワイトリスト型で検証するのがデフォルトです。

4. 入力バリデーション

入力バリデーションとは入力が正しく妥当であることを検証することです。セキュリティ対策で最も重要な入力バリデーションは信頼境界で行います。

以下の2つの原則が重要です。

• Fail Fast原則 – 失敗するモノはできる限り早く失敗させる
• 単一責任原則 – １つのモジュール／クラスは単一の責任を果す

Fail Fast原則から「最外周の信頼境界」が最も重要になります。

単一責任原則はプログラムの基本構造である「入力 ⇒ 処理 ⇒ 出力」に当てはめることができます。

Fail Fast原則と単一責任原則を当てはめると

• 入力 – 入力処理の責任を果す。（入力値の形式的妥当性を検証 = 入力値の形式／範囲の検証）
• 処理 – ロジック処理の責任を果す。（入力値の論理的妥当性の検証 ＝ 入力値の論理的／仕様的検証）
• 出力 – 出力処理の責任を果す。（「出力無害化」を行う。これは後述の「多層防御」で行う）

となります。同じ検証でも、入力処理とロジック処理で行う検証は異るモノです。

5. 出力無害化

外部システム（プログラム内に組み込まれているライブラリ、正規表現やXMLなど、も含む）に出力する場合、全ての出力を完全に無害化します。出力対策と入力対策は独立した対策です。

次の3つの何れか、又はその組み合わせで対策します。

• エスケープ（エンコーディング – 無害なデータに変換）
• 安全なAPI（エスケープが必要ないAPI – 有害な動作を不可能にするAPI）
• バリデーション（無害なデータであることを検証）

出力先のコンテクストを理解し、それぞれのコンテクスト用に無害化処理を行わないと無害化できません。

「安全なAPI」を使っていれば安全とは限りません。APIを使う場合もコンテクストが重要です。例えば、プリペアードクエリは静的SQLのみ使っている時は安全ですが、それ以外（プリペア文に変数埋め込み＝動的SQL）では安全ではありません。”コンテクスト”を意識していないと、思わぬ勘違いをしてしまいます。

6. 多層防御

文字通り、複数のレイヤーで防御を行う概念です。単一の防御より複数の防御の方がより安全になります。セキュアコーディングでは”出力対策は独立した対策”であることを求めています。セキュアコーディングを行う場合には、「全ての変数を完全に無害化してから出力する」が必要です。

7. 必要十分条件

論理的に物事を考えて、論理的に誤りのない構造や仕組み、実装にするという概念が欠けているとセキュリティ設計レベルで誤りを起こしやすくなります。必要十分条件となっているか？必要十分条件を満たすための前提条件は何か？を考えると間違いが少くなります。

必要十分条件は、条件pとqがある場合に以下の両方が成り立つ

• p ⇒ q
• q ⇒ p

例：

• プログラムの実行が正しい ⇒ 入力と出力が正しい
• 但し、ロジックは正しいものと仮定する

この例の条件qを”出力が正しい”と変えると必要十分条件になりません。プログラムはプログラムが受け入れ可能な入力でしか、正しく動作しません。（例：整数オーバーフロー、商品コードに'<script>alert(“XSS”)</script>’）

ITセキュリティの概念というより論理的思考の基礎知識ですが、論理的に成り立たないセキュリティ対策や方法論が在ったりします。この為、これも項目に入れています。

8. ITセキュリティ対策の目的

• ITセキュリティ対策の目的： ITシステムを許容可能な範囲のリスクに抑えて利用する

目的が明確でない場合、簡単に”手段”と”目的”の勘違いが生まれます。セキュリティ対策の目的はITシステムを利用することにあり、セキュリティ対策するという”手段”が目的になるのは誤りです。

9. ITセキュリティ対策の定義

• ITセキュリティ対策の定義：リスクを変化させるモノ全てに対応し、これらを管理すること

「リスクを減らす対策」「リスクを廃除する対策」といったモノが「セキュリティ対策」と勘違いしているケースはよく見かけます。「リスクを増加」させたり「リスクを許容」し管理することもセキュリティ対策の１つです。※

10. ISO 27000

ISO 27000はISMS認証の基盤です。国内だけでも5000以上の組織がISMS認証を取得している国際ITセキュリティ標準です。これに合致しないセキュリティ概念ではコミュニケーションが成り立ちません。

まとめ

かなりざっくりと短くまとめました。解りづらい場合はロング版をご覧ください。

ロング版はこちら