DNET_SCSystemDevelopment

SC：システム開発

• 戻る（試験）
  • 基礎
  • 脅威
  • 脆弱性
  • 対策技術
  • システム開発（本ページ）
  • マネジメント
  • 法制度

概要

システム開発工程とセキュリティ対策

工程毎の実施例

要件定義

工程（要件定義）

・・・

実施（要件定義）

• セキュリティ基本方針の決定
  • セキュリティ目標
  • セキュリティ品質管理体制
  • 適用準拠するセキュリティ規格・基準

方式設計

工程（方式設計）

・・・

実施（方式設計）

• リスク分析の実施

• セキュリティ要件の決定

  • セキュリティ基本要件の決定

    • セキュリティ目標
    • 適用 / 準拠 基準
    • セキュリティ基本要件

  • セキュリティ実装要件の決定

    • 識別 / 認証
    • アクセス制御
    • データ保護（暗号化）
    • セキュリティ監視
    • セキュリティ監査
    • マルウェア対策
    • DoS攻撃対策

  • アプリケーション・セキュリティ要件の決定

    • 開発環境のセキュリティ対策要件
    • アプリケーション特性からのセキュリティ要件
    • セキュリティ・テスト方式に関する要件

  • システム・セキュリティ管理要件の決定

    • ID管理
    • 鍵管理
    • パッチ管理
    • 構成 / 設定 / 変更管理
    • ログ管理
    • インシデント / 問題 管理

基本・詳細設計

工程（基本・詳細設計）

• UI設計
• システム構造設計
• プログラム構造設計

実施（基本・詳細設計）

• セキュリティ設計 / 構築手順書の整備

  • システム領域

    • 要件：セキュリティ実装要件、システム・セキュリティ管理要件
    • ネットワーク、サーバ機器、セキュリティ製品の構成決定
    • 構築手順書の整備

  • プログラミング領域

    • 要件：セキュリティ実装要件、アプリケーション・セキュリティ要件
    • プログラム構成の決定
    • 共通モジュール、モジュール間I/F仕様の決定

• セキュア・プログラミング・ガイド文書の整備

  • 文書の整備
  • 開発要員の教育

構築、PG、UT

工程（構築、PG、UT）

• システム基盤構築
• プログラミング
• プログラムテスト

実施（構築、PG、UT）

• セキュア・システム基盤構築

  • サーバーは「ホストの要塞化」
  • セキュリティ製品による対策

• セキュア・プログラミング

  • プログラム開発
  • ソースコード・レビュー（ホワイト・ボックス）
    • 専門家によるレビュー
    • ツールによるレビュー

テスト

工程（テスト）

• 結合テスト
• システム・テスト
• 運用テスト→移行

実施（テスト）

本番前の脆弱性検査 / 診断（セキュリティ脆弱性対策ツールの該当節を参照）

運用・保守

工程（運用・保守）

・・・

実施（運用・保守）

本番前の脆弱性検査 / 診断（セキュリティ脆弱性対策ツールの該当節を参照）

言語毎の留意点

C/C++

バッファ・オーバーフロー（BOF）系

• プログラミングによるBOF対策

OSコマンド・インジェクション

• 実践だったら、そもそもサニタイジング・ライブラリ無いなら、
• ユーザ入力をOSコマンドの入力にもっていくなという話だが、
• 試験的には、徹底的にメタ文字をチェックしろとしか書いておらず、
• 具体的に、何をチェックすればOKという話まで書かれていない。

Java

• Java

セキュリティ機構

• サンドボックス・モデル
  （コード・アクセス・セキュリティのような仕組）

  • ローカル
  • 外部
    • ネットワーク

• セキュリティ・ポリシ

  • 設定項目

    • 署名者（signedBy）
    • コードの場所（codeBase）
    • アクセス権（permission）

  • 設定箇所

    • システム・ポリシーファイル ({java.home} 以下)
    • ユーザ・ポリシーファイル ({user.home} 以下)

• クラスローダ

  • アクセス権を持ったクラス・オブジェクトの定義
  • 上記を統合して、クラスを実行時インストールする
    • サンドボックス・モデル
    • セキュリティ・ポリシ

• セキュリティモデル

  • セキュリティ・マネージャ

    • セキュリティモデルを、セキュリティ・マネージャに委ねる場合。
    • System.getSecurityManagerでSecurityManagerクラスを取得し、
    • security.checkXXXXメソッドでチェックする。

  • アクセス・コントローラ

    • 特定のセキュリティモデルを使用する場合、
    • XXXXPermissionクラスをnewし、
    • AccessController.checkPermissionメソッドでチェックする。

レース・コンディション

• 変数
  主に、Instance変数ではない、
  static変数により競合が発生する。

• RDBMSレコード
  仮予約などの機構で競合し、
  他人の予約を参照できてしまう。

その他（Java）

• 公開不要なメソッド、メンバ変数は、Publicではなく、Privateに設定

• 不要な、setter / getterは、Interfaceに定義しない
  （そして、ユーザはClassではなくInterfaceを利用）。

• 継承の末端Classにはfinalを付与

ECMAScript

• ECMAScript

留意点

グローバル変数でvarを省略しない
（本来、別々の変数が同じ値になったりする）。

その他（ECMAScript）

• Cookieを使用可能。

• Ajax

  • クライアント側ライブラリとしてXMLHttpRequestを使う。
    • クロス ドメイン接続に注意する。
  • データ・フォーマットとしては主にJSONを使う。
    • eval()は危険なので、JSON.parse()を使用する。

セキュリティ規格・基準

ISO/IEC 15408

• 高度午前 - 技術要素 - セキュリティの該当節を参照。

PCI DSS

• 高度午前 - 技術要素 - セキュリティの該当節を参照。

ASVS

OWASP の ASVS

• ASVS : Application Security Verification Standard
• アプリケーションセキュリティ検証標準

移行メモ

• 「運用・保守」の「実施」が「テスト」と同じ「本番前の脆弱性検査 / 診断」に なっているのは原文ママ（運用・保守では定期的な実施を指すものと思われる）。
• 元 Wiki で見出しそのものが他ページへのリンクになっていた箇所 （「バッファ・オーバーフロー（BOF）系」「Java」「ECMAScript」 「ISO/IEC 15408」「PCI DSS」）は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
• 同名の見出しが多数あり GitHub Wiki でアンカが衝突するため、括弧で文脈を補って一意にした （工程毎の「工程」「実施」の各 6 箇所、「その他（Java）」「その他（ECMAScript）」）。
• マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への URL リンクは、移行済みの コード・アクセス・セキュリティ / クロス ドメイン接続 / JSON に張り替えた。
• PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
• 未移行のページはファイル名を予約し、TODO.md に記録した。

---

Tags: 移行, 資格, SC, システム開発, セキュア・プログラミング, BOF, OSコマンド・インジェクション, Java, ECMAScript, ISO/IEC 15408, PCI DSS, ASVS