DNET_SCBasics

SC：基礎

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

概念

セキュリティと情報セキュリティ

セキュリティ

• 広義には安全（セーフティ）も含まれる。

• BCP（事業継続計画）とCP（緊急時対応計画）とDR（災害復旧）の違い

  • 共通項
    企業が自然災害、大火災、テロ攻撃などの緊急事態に遭遇した場合において、
    事業資産の損害を最小限に止め、中核事業の継続・早期復旧を可能とする。

  • BCP(Business Continuity Plan)

    • 事業継続を目的としている。
    • 事「前」に行っておくべきことを定めている。
    • ちなみに、BCMはBCP策定のためのマネジメント。

  • CP (Contingency Plan)

    • 被害を最小限に抑えることを目的としている。
    • 非常事態発生「後」の対応計画に焦点を当てる。
      ・予防、検知、対応がスコープになる。
      ・初動計画に力点を置いている。

  • DR (Disaster Recovery)

    • システムの正常な運用を脅かす不測の事態が生じた際に、
      システムの停止による損失を最小限に抑える様々な手段や手順の総体。

    • 不測の事態には以下を含む。
      ・地震や風水害などの自然災害、
      ・事故や停電、火災、テロ、サイバー攻撃
      ・機器の故障や、人的な脅威（偶発的、意図的）。

※ 参考（マネジメントの該当節を参照）

情報セキュリティ

• 情報の機密性、完全性および可用性を維持すること。

  • 機密性 (confidentiality):

    • 許可されていない個人、エンティティ又は
      プロセスに対して、情報を使用不可又は非公開にする特性
    • 認証・認可系の各種技術（認証システムとアクセス許可）

  • 完全性 (integrity):

    • 資産の正確さ及び完全さを保護する特性
    • 正当性、正確性、網羅性、一貫性（ハッシュ・署名）

  • 可用性 (availability):

    • 許可されたエンティティが要求したときに、アクセス及び使用が可能である特性
    • 冗長化、復旧

• さらに、真正性、責任追跡性、否認防止および
  信頼性のような特性を維持することを含めてもよい。

  • 真正性 (authenticity):

    • ある主体（subject）又は資源が、主張（claim）どおりであることを確実にする特性。
    • 人の特定（Password、IC、生体情報、ディジタル署名）

  • 責任追跡性 (accountability):

    • あるエンティティの動作が、
      その動作から動作主のエンティティまで
      一意に追跡できる事を確実にする特性。
    • ログ

  • 否認防止 (non-repudiation):

    • ある活動又は事象が起きたことを、後になって否認されないように証明する能力
    • 通常データ完全性を証明するハッシュ・署名・タイムスタンプ

  • 信頼性 (reliability):

    • 意図した動作及び結果に一致する特性
    • バグがないこと

• 関連

  • デジタル・フォレンジック
    （高度午前 - 技術要素 - セキュリティの該当節を参照）
    • 責任追跡性 (accountability)
    • 否認防止 (non-repudiation)

情報セキュリティ特性

公共的なシステムでは、完全性と可用性が重要になる。

基本的特性

前述の情報セキュリティの定義そのもの。

• 機密性 (confidentiality)
• 完全性 (integrity)
• 可用性 (availability)

付加的特性

前述の情報セキュリティの拡張的。

• 真正性 (authenticity)
• 責任追跡性 (accountability)
• 否認防止 (non-repudiation)
• 信頼性 (reliability)

物理的セキュリティと論理的セキュリティ

物理的セキュリティ

物理的なセキュリティ（耐震、防火、電源、回線、入退館

論理的セキュリティ

• 物理的セキュリティを除くほか全て。

• 以下の３つに分類できる。

  • 管理的セキュリティ（運用管理）

  • 人的セキュリティ（教育・訓練・懲戒）

  • システム的セキュリティ（技術）

情報セキュリティ対策

機能

予防

• 抑止・抑制：

  • 脅威の発生を減らす
  • （人の意識やモラルに対する）相互牽制

• 予防・防止：

  • 脅威を避ける、脆弱性を減らす
  • 技術的なシステム脆弱性対策の実施

検知

• 検知・追跡：

  • 脅威または脆弱性を早く発見し、対応する
  • ログ取得・解析、稼働監視・記録、IDPS、IPS/WAF

• 回復：

  • 早くあるべき状態に復旧する
  • バックアップ・リストア、手順

考え方

リスク・アセスメント

• ～リスク定量分析（PMP：計画 - リスクの該当節を参照）的な。

  • 「リスク」＝「資産」の価値×「脅威」の大きさ×「脆弱性」の程度
  • 「アセスメント」＝物事の総体としての量・価値の計算的評価。

• コンテンツ

  • 守るべきものを認識する。

    • 情報資産
    • システム等

  • 脅威を知る。
    攻撃の手段など。

  • 脆弱性を知り対処する。
    脆弱性の内容と対策の方法。

方針、基準、手順の整備

リスク対応計画（PMP：計画 - リスクの該当節を参照）的な。

• 情報セキュリティ（のマネジメント・システム）の確立

• 方針、基準

  • 対策有効性の第三者レビュー

  • バランス

    • セキュリティ
    • 利便性

  • インシデント

  • 未然防止

  • 発生時対処

  • 原則徹底

    • 最小権限
    • 職務分離

  • ネットワーク

    • 重要情報システムとインターネットの分離

  • システム

    • フェールセーフ
    • 構成・機能の単純化
    • 重要な機能・設備の分散化
    • 多層防御（２重・３重の対策）
    • 付加的特性関連
      認証（識別・特定）やデジタル・フォレンジック（追跡・検証）

情報セキュリティ・マネジメント

• 情報セキュリティ（のマネジメント・システム）

情報セキュリティ特性を情報セキュリティ対策により維持・管理する。

PDCA

PDCAの4ステップを繰り返しながら継続的に推進されていくのが望ましいとされる。

• P : 策定

• D :

  • 教育
  • 管理
  • 導入
  • 運用

• C : 監査

• A : 是正

ISMS

• ISMS（情報セキュリティ・マネジメント・システム）は
  SCの該当節を参照。

制度の概要

• 年表

  • 2001/4より開始
  • 1年間はパイロット運用期間
  • 2002/4より本格運用
  • 2006よりISO/IEC, JIS化

• ISMSの認証@日本

  • 名称 : ISMS適合性評価制度
  • JIPDECが認証機関を運営している
    • 一般財団法人日本情報経済社会推進協会
    • JIPDEC : Japan Institute for Promotion of Digital Economy and Community

• 運用体制

  • JIPDEC

  • 認証関連

    • 認証機関
    • 評価希望組織

  • 審査員関連

    • 要員認証機関
    • 審査員研修機関
    • 審査員希望者

• 審査の流れ

  • 認証前審査

    • 予備審査（任意）
    • 文書審査（ステップ１）
    • 実地審査（ステップ２）

  • 認証後審査

    • 継続審査（サーベイランス）
      半年 - １年に一回実施。

    • 更新審査
      ３年に一回、認証前審査と同じ。

確立と運用の各作業

• 確立

  • ステップ０：認証取得準備

    • 立上
    • 経営資源割当
    • スケジュール決定

  • ステップ１：適用範囲・境界の定義

    • 適用範囲（組織, 情報システム, etc.）
    • 境界定義（事業, 組織, 拠点, etc.）

  • ステップ２：方針の確立

  • ステップ３：アセスメントに関する決定

    • 方法の特定
    • 受容基準の設定

  • ステップ４：リスク特定

    • 管理責任者の特定
    • 脅威、脆弱性の洗い出し
    • リスクの特定

  • ステップ５：リスクの分析・評価

    • リスクの分析（リスク・レベルの算出）
    • リスクの評価（受容基準から対応の必要性の有無を検討）

  • ステップ６：リスク対応の選択肢の特定・評価

    • リスク対応の選択肢の特定
    • リスク対応の選択肢の評価

  • ステップ７：リスク対応の管理策の決定

    • 管理策の見落としの確認（附属書Aと比較）
    • 管理策の適用後の残留リスクの算出
    • 管理策の文書化（実施基準、実施手順）
    • 実施に伴う文書化（記録、証拠）

  • ステップ８：残留リスクの承認
    リスク所有者から残留リスクの承認を得る

  • ステップ９：適用宣言書の作成

    • 管理策に対応する管理目的・選択理由
    • 実施済みの管理策
    • 除外した管理策の正当性
    • 管理策の文書化（実施基準、実施手順）
    • 実施に伴う文書化（記録、証拠）

• 運用

  • 管理策の実施

  • ISMSの浸透

    • 教育実施
    • ポスター、キャッチコピー
    • ハンドブックの作成・配布

  • 記録収集
    管理策実施の記録収集

  • 内部監査

  • 問題改善

適合性評価制度

• 法制度の該当節（マネジメント系）を参照。

ネットワーク

以下は、いずれもネットワークの基礎編ほか、 マイクロソフト系技術情報 Wiki の該当節を参照。

• IPv4, v6（ネットワークの基礎編）
• UDP, TCP（ネットワークの基礎編）
• DNS（DNSサーバ）
• プロトコル（ネットワークの基礎編）
  • ICMP
  • メール
  • HTTP

仮想化、クラウド

仮想化技術

• 仮想化アーキテクチャ

仮想デスクトップ、デスクトップ仮想化

VDI、シンクライアントとも呼ばれる。
IPA定義が仮想化技術と違うのでこっちに書く。

実現方式

方式	特徴
ネットワーク・ブート方式	ネットワークからブート領域をダウンロードして実行（MED-V、XenClient）
画面転送方式	サーバで実行し画面のみを転送する（RDS、XenApp、XenDesktop）。

画面転送方式の分類

方式	特徴
サーバーベース型	サーバのマルチ ユーザ化（RDS、XenApp）
ブレードPC型	１ブレード、１デスクトップPC（某社のナントカSymphonyとか）
VDI型	１VM、１デスクトップPC（XenDesktop）

※ 今日日は、ほぼ、VDI型の画面転送方式なんじゃなかろうか？

クラウド

• クラウドの基本（クラウド）
• クラウド利用時の注意事項

移行メモ

• 「BCMはBPC策定のためのマネジメント」→「BCP策定のための」に正した。
• 「債務分離」→「職務分離」に正した（最小権限と並ぶ原則）。
• 「サーバで実行し画面の未転送する」→「画面のみを転送する」に正した。 また「RSD」は Windows のリモートデスクトップ サービスの略号としては 「RDS」であるため正した（2 箇所）。
• 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所 （「情報セキュリティ・マネジメント」「ISMS」「適合性評価制度」 「ネットワーク」配下の各見出し、「仮想化技術」「クラウドの基本」 「クラウド利用時の注意事項」）は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。 「ネットワーク」配下は見出しのみで本文が無かったため、箇条書きにまとめた。
• マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への URL リンクは、移行済みの ネットワークの基礎編 / DNSサーバ / 仮想化アーキテクチャ / クラウド / クラウド利用時の注意事項 に張り替えた。
• PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
• 未移行のページはファイル名を予約し、TODO.md に記録した。

---

Tags: 移行, 資格, SC, 情報セキュリティ, CIA, BCP, DR, ISMS, PDCA, VDI, シンクライアント, クラウド