「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概念 †
セキュリティと情報セキュリティ †
セキュリティ †
- BCP（事業継続計画）とCP（緊急時対応計画）とDR（災害復旧）の違い
- 共通項
企業が自然災害、大火災、テロ攻撃などの緊急事態に遭遇した場合において、
事業資産の損害を最小限に止め、中核事業の継続・早期復旧を可能とする。
- BCP(Business Continuity Plan)
- 事業継続を目的としている。
- 事「前」に行っておくべきことを定めている。
- ちなみに、BCMはBPC策定のためのマネジメント。
- CP (Contingency Plan)
- 被害を最小限に抑えることを目的としている。
- 非常事態発生「後」の対応計画に焦点を当てる。
・予防、検知、対応がスコープになる。
・初動計画に力点を置いている。
- システムの正常な運用を脅かす不測の事態が生じた際に、
システムの停止による損失を最小限に抑える様々な手段や手順の総体。
- 不測の事態には以下を含む。
・地震や風水害などの自然災害、
・事故や停電、火災、テロ、サイバー攻撃
・機器の故障や、人的な脅威（偶発的、意図的）。
※ 参考
情報セキュリティ †
- 機密性 (confidentiality):
- 許可されていない個人、エンティティ又は
プロセスに対して、情報を使用不可又は非公開にする特性
- 認証・認可系の各種技術（認証システムとアクセス許可）
- 完全性 (integrity):
- 資産の正確さ及び完全さを保護する特性
- 正当性、正確性、網羅性、一貫性（ハッシュ・署名）
- 可用性 (availability):
- 許可されたエンティティが要求したときに、アクセス及び使用が可能である特性
- 冗長化、復旧
- さらに、真正性、責任追跡性、否認防止および
信頼性のような特性を維持することを含めてもよい。
- 真正性 (authenticity):
- ある主体（subject）又は資源が、主張（claim）どおりであることを確実にする特性。
- 人の特定（Password、IC、生体情報、ディジタル署名）
- 責任追跡性 (accountability):
- あるエンティティの動作が、
その動作から動作主のエンティティまで一意に追跡できる事を確実にする特性。
- ログ
- 信頼性 (reliability):
- 意図した動作及び結果に一致する特性
- バグがないこと
- 否認防止 (non-repudiation):
- ある活動又は事象が起きたことを、後になって否認されないように証明する能力
- 通常データ完全性を証明するハッシュ・署名・タイムスタンプ
物理的セキュリティと論理的セキュリティ †
物理的セキュリティ †
物理的なセキュリティ（耐震、防火、電源、回線、入退館
論理的セキュリティ †
特性 †
公共的なシステムでは、完全性と可用性が重要になる。
基本的特性 †
前述の情報セキュリティの定義そのもの。
付加的特性 †
前述の情報セキュリティの拡張的。
- 真正性 (authenticity)
- 責任追跡性 (accountability)
- 否認防止 (non-repudiation)
- 信頼性 (reliability)
対策 †
機能 †
予防 †
- 抑止・抑制：
- 脅威の発生を減らす
- （人の意識やモラルに対する）相互牽制
- 予防・防止：
- 脅威を避ける、脆弱性を減らす
- 技術的なシステム脆弱性対策の実施
検知 †
- 検知・追跡：
- 脅威または脆弱性を早く発見し、対応する
- ログ取得・解析、稼働監視・記録、IDPS、IPS/WAF
- 回復：
- 早くあるべき状態に復旧する
- バックアップ・リストア、手順
考え方 †
リスク・アセスメント †
- ～リスク定量分析的な。
- 「リスク」＝「資産」の価値×「脅威」の大きさ×「脆弱性」の程度
- 「アセスメント」＝物事の総体としての量・価値の計算的評価。
- 脆弱性を知り対処する。
脆弱性の内容と対策の方法。
方針、基準、手順の整備 †
リスク対応計画的な。
- システム
- フェールセーフ
- 構成・機能の単純化
- 重要な機能・設備の分散化
- 多層防御（２重・３重の対策）
- 付加的特性関連
認証（識別・特定）やデジタル・フォレンジック（追跡・検証）
PDCA †
PDCAの4ステップを繰り返しながら継続的に推進されていくのが望ましいとされる。
制度の概要 †
- 年表
- 2001/4より開始
- 1年間はパイロット運用期間
- 2002/4より本格運用
- 2006よりISO/IEC, JIS化
- ISMSの認証@日本
- 名称 : ISMS適合性評価制度
- JIPDECが認証機関を運営している
- 一般財団法人日本情報経済社会推進協会
- JIPDEC : Japan Institute for Promotion of Digital Economy and Community
- 認証前審査
- 予備審査（任意）
- 文書審査（ステップ１）
- 実地審査（ステップ２）
- 継続審査（サーベイランス）
半年 - １年に一回実施。
確立と運用の各作業 †
- ステップ１：適用範囲・境界の定義
- 適用範囲（組織, 情報システム, etc.）
- 境界定義（事業, 組織, 拠点, etc.）
- ステップ４：リスク特定
- 管理責任者の特定
- 脅威、脆弱性の洗い出し
- リスクの特定
- ステップ５：リスクの分析・評価
- リスクの分析（リスク・レベルの算出）
- リスクの評価（受容基準から対応の必要性の有無を検討）
- ステップ６：リスク対応の選択肢の特定・評価
- リスク対応の選択肢の特定
- リスク対応の選択肢の評価
- ステップ７：リスク対応の管理策の決定
- 管理策の見落としの確認（附属書Aと比較）
- 管理策の適用後の残留リスクの算出
- 管理策の文書化（実施基準、実施手順）
- 実施に伴う文書化（記録、証拠）
- ステップ８：残留リスクの承認
リスク所有者から残留リスクの承認を得る
- ステップ９：適用宣言書の作成
- 管理策に対応する管理目的・選択理由
- 実施済みの管理策
- 除外した管理策の正当性
- 管理策の文書化（実施基準、実施手順）
- 実施に伴う文書化（記録、証拠）
- ISMSの浸透
- 教育実施
- ポスター、キャッチコピー
- ハンドブックの作成・配布
ネットワーク †
仮想化、クラウド †
VDI、シンクライアント †
IPA定義がリンク先と違うのでこっちに書く。
- 実現方式
| 方式 | 特徴 |
| ネットワーク・ブート方式 | ネットワークからブート領域をダウンロードして実行（MED-V、XenClient?） |
| 画面転送方式 | サーバで実行し画面の未転送する（RSD、XenApp?、XenDesktop?）。 |
- 画面転送方式の分類
| 方式 | 特徴 |
| サーバーベース型 | サーバのマルチ ユーザ化（RSD、XenApp?） |
| ブレードPC型 | １ブレード、１デスクトップPC（ナントカSymphonyとか） |
| VDI型 | １VM、１デスクトップPC（XenDesktop?） |
クラウド †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
