.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概念

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

セキュリティ

  • 広義には安全(セーフティ)も含まれる。
  • BCP(事業継続計画)とCP(緊急時対応計画)とDR(災害復旧)の違い
  • 共通項
    企業が自然災害、大火災、テロ攻撃などの緊急事態に遭遇した場合において、
    事業資産の損害を最小限に止め、中核事業の継続・早期復旧を可能とする。
  • BCP(Business Continuity Plan)
    • 事業継続を目的としている。
    • 事「前」に行っておくべきことを定めている。
    • ちなみに、BCMはBPC策定のためのマネジメント。
  • CP (Contingency Plan)
    • 被害を最小限に抑えることを目的としている。
    • 非常事態発生「後」の対応計画に焦点を当てる。
      ・予防、検知、対応がスコープになる。
      ・初動計画に力点を置いている。
  • DR (Disaster Recovery)
  • システムの正常な運用を脅かす不測の事態が生じた際に、
    システムの停止による損失を最小限に抑える様々な手段や手順の総体。
  • 不測の事態には以下を含む。
    ・地震や風水害などの自然災害、
    ・事故や停電、火災、テロ、サイバー攻撃
    ・機器の故障や、人的な脅威(偶発的、意図的)。

参考

情報セキュリティ

  • 情報の機密性、完全性および可用性を維持すること。
  • 機密性 (confidentiality):
    • 許可されていない個人、エンティティ又は
      プロセスに対して、情報を使用不可又は非公開にする特性
    • 認証・認可系の各種技術(認証システムとアクセス許可)
  • 完全性 (integrity):
    • 資産の正確さ及び完全さを保護する特性
    • 正当性、正確性、網羅性、一貫性(ハッシュ・署名)
  • 可用性 (availability):
    • 許可されたエンティティが要求したときに、アクセス及び使用が可能である特性
    • 冗長化、復旧
  • さらに、真正性、責任追跡性、否認防止および
    信頼性のような特性を維持することを含めてもよい。
  • 真正性 (authenticity):
    • ある主体(subject)又は資源が、主張(claim)どおりであることを確実にする特性。
    • 人の特定(Password、IC、生体情報、ディジタル署名)
  • 責任追跡性 (accountability):
    • あるエンティティの動作が、
      その動作から動作主のエンティティまで一意に追跡できる事を確実にする特性。
    • ログ
  • 信頼性 (reliability):
    • 意図した動作及び結果に一致する特性
    • バグがないこと
  • 否認防止 (non-repudiation):
    • ある活動又は事象が起きたことを、後になって否認されないように証明する能力
    • 通常データ完全性を証明するハッシュ・署名・タイムスタンプ

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

物理的セキュリティ

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

論理的セキュリティ

  • 以下の3つに分類できる。
  • 管理的セキュリティ(運用管理)
  • 人的セキュリティ(教育・訓練・懲戒)
  • システム的セキュリティ(技術)

特性

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

基本的特性

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

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

付加的特性

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

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

対策

機能

予防

  • 抑止・抑制:
    • 脅威の発生を減らす
    • (人の意識やモラルに対する)相互牽制
  • 予防・防止:
    • 脅威を避ける、脆弱性を減らす
    • 技術的なシステム脆弱性対策の実施

検知

  • 検知・追跡:
    • 脅威または脆弱性を早く発見し、対応する
    • ログ取得・解析、稼働監視・記録、IDPS、IPS/WAF
  • 回復:
    • 早くあるべき状態に復旧する
    • バックアップ・リストア、手順

考え方

リスク・アセスメント

  • リスク定量分析的な。
    • 「リスク」=「資産」の価値×「脅威」の大きさ×「脆弱性」の程度
    • 「アセスメント」=物事の総体としての量・価値の計算的評価。
  • コンテンツ
  • 守るべきものを認識する。
    • 情報資産
    • システム等
  • 脆弱性を知り対処する。
    脆弱性の内容と対策の方法。

方針、基準、手順の整備

リスク対応計画的な。

  • 方針、基準
  • 対策有効性の第三者レビュー
  • バランス
    • セキュリティ
    • 利便性
  • インシデント
  • 未然防止
  • 発生時対処
  • 原則徹底
    • 最小権限
    • 債務分離
  • ネットワーク
    • 重要情報システムとインターネットの分離
  • システム
    • フェールセーフ
    • 構成・機能の単純化
    • 重要な機能・設備の分散化
    • 多層防御(2重・3重の対策)
    • 付加的特性関連
      認証(識別・特定)やデジタル・フォレンジック(追跡・検証)

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

PDCA

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

  • P : 策定
  • D :
    • 教育
    • 管理
    • 導入
    • 運用
  • C : 監査
  • A : 是正

ISMS

制度の概要

  • 年表
    • 2001/4より開始
    • 1年間はパイロット運用期間
    • 2002/4より本格運用
    • 2006よりISO/IEC, JIS化
  • ISMSの認証@日本
    • 名称 : ISMS適合性評価制度
    • JIPDECが認証機関を運営している
      • 一般財団法人日本情報経済社会推進協会
      • JIPDEC : Japan Institute for Promotion of Digital Economy and Community
  • 運用体制
    • JIPDEC
  • 認証関連
    • 認証機関
    • 評価希望組織
  • 審査員関連
    • 要員認証機関
    • 審査員研修機関
    • 審査員希望者
  • 審査の流れ
  • 認証前審査
    • 予備審査(任意)
    • 文書審査(ステップ1)
    • 実地審査(ステップ2)
  • 認証後審査
  • 継続審査(サーベイランス)
    半年 - 1年に一回実施。
  • 更新審査
    3年に一回、認証前審査と同じ。

確立と運用の各作業

  • 確立
  • ステップ0:認証取得準備
    • 立上
    • 経営資源割当
    • スケジュール決定
  • ステップ1:適用範囲・境界の定義
    • 適用範囲(組織, 情報システム, etc.)
    • 境界定義(事業, 組織, 拠点, etc.)
  • ステップ2:方針の確立
  • ステップ3:アセスメントに関する決定
    • 方法の特定
    • 受容基準の設定
  • ステップ4:リスク特定
    • 管理責任者の特定
    • 脅威、脆弱性の洗い出し
    • リスクの特定
  • ステップ5:リスクの分析・評価
    • リスクの分析(リスク・レベルの算出)
    • リスクの評価(受容基準から対応の必要性の有無を検討)
  • ステップ6:リスク対応の選択肢の特定・評価
    • リスク対応の選択肢の特定
    • リスク対応の選択肢の評価
  • ステップ7:リスク対応の管理策の決定
    • 管理策の見落としの確認(附属書Aと比較)
    • 管理策の適用後の残留リスクの算出
    • 管理策の文書化(実施基準、実施手順)
    • 実施に伴う文書化(記録、証拠)
  • ステップ8:残留リスクの承認
    リスク所有者から残留リスクの承認を得る
  • ステップ9:適用宣言書の作成
    • 管理策に対応する管理目的・選択理由
    • 実施済みの管理策
    • 除外した管理策の正当性
    • 管理策の文書化(実施基準、実施手順)
    • 実施に伴う文書化(記録、証拠)
  • 運用
  • 管理策の実施
  • ISMSの浸透
    • 教育実施
    • ポスター、キャッチコピー
    • ハンドブックの作成・配布
  • 記録収集
    管理策実施の記録収集
  • 内部監査
  • 問題改善

ネットワーク

IPv4, v6

TCP, UDP

DNS

プロトコル

ICMP

メール

HTTP

仮想化、クラウド

仮想化技術

VDI、シンクライアント

IPA定義がリンク先と違うのでこっちに書く。

  • 実現方式
    方式特徴
    ネットワーク・ブート方式ネットワークからブート領域をダウンロードして実行(MED-V、XenClient?
    画面転送方式サーバで実行し画面の未転送する(RSD、XenApp?XenDesktop?)。
  • 画面転送方式の分類
    方式特徴
    サーバーベース型サーバのマルチ ユーザ化(RSD、XenApp?
    ブレードPC型1ブレード、1デスクトップPC(ナントカSymphonyとか)
    VDI型1VM、1デスクトップPC(XenDesktop?

クラウド

クラウドの基本

クラウド利用時の注意事項


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-09-01 (日) 12:00:24 (46d)