スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

[職] [高] 午前メモその3

試験関連メモその3。(高度)


■監査

●内部統制(internal control)
重要なだけに、必ず出る。試験がどうこうを抜きにして知っておかないとだめ

・業務の適正を確保するため(不正をさせないため)の仕組み。
 あらゆる組織において、ルールや、業務プロセス、体制、権限に、互いを
 けん制・見張り・チェックするような仕組み・システムを入れることによって、
 健全性や効率性を保つようにする。
 本来は、金融(金融庁・会計士)から来る概念だが、日本では
 総務、組織管理の枠で語られることが多いようである

・主な目的4つ
 - 事業目標達成のための、業務の有効性・効率性
 - 財務報告の信頼性担保
 - 法令遵守(法律、会計基準、規範、企業倫理ガイドライン)
 - 資産の保全(有形・無形、人的資源も含む資産の使用・処分のプロセスの適正化)

 キーワードとしては、健全性/信頼性、効率性、有効性あたり。
 要するに「不正なことしていないよね?」ということを摘出し防止・是正に
 つなげられるようにするのが目的で、そのための手段としてルールやプロセス
 体制、権限といった話が出てきている。

・法律での義務付け
 - 平成16年5月の会社法で、業務全般に内部統制を整備・運用することが、
  大会社とその関連会社に義務付けられた。
 - 内部統制報告書:整備状況、有効性評価
 - メリットとして信頼性向上、リスクへの対策があるものの、コストが課題

・監査との関連
 - 二重責任の原則: 経営者が作成した内部統制報告書を、公認会計士が監査
  ⇒ 金融商品取引法
 - 会計監査手順: 内部統制報告書から公認会計士が作成する。
 - 監査: 公認会計士が会計監査手順により監査するが、
  そのインプットとなるのが内部統制報告書。
 - ちなみに、この報告を偽った場合は、5年以下の懲役または500万円以下の罰金、
  またはその両方が課せられる

・内部統制の実務の枠組み
 企業会計審議会・内部統制部会による
 「財務報告に係る内部統制の評価及び監査の基準」
 「財務報告に係る内部統制の評価及び監査に関する実施基準」

・大会社
 会社法2条6号。株式会社の一種。貸借対照表において
 資本金の額が5億円以上、または、負債の合計額が200億円以上
 の会社を指す。

・SOX法
 - サーベンス・オクスリー法。正式名称はちょっと長い。
  ⇒ 上場企業会計改革および投資家保護法
 - 投資家の保護が目的であり、
  企業の会計・財務諸表の信頼性向上のために、
  財務報告プロセス厳格化と規制の法制化を定めている
 - 2002年7月に成立した米国の連邦法である。
  日本では企業改革法と呼ぶ人もいる。

・基本要素
 - 統制環境: 組織を構成する各人の意識への影響
 - リスク評価、対応: 事業目標の阻害要因の分析、対策
 - 統制活動: 方針と手続き
 - 情報伝達: 目的に照らして必要な情報が必要な人に届く
 - モニタリング: 継続的に監視、是正
 - IT: 財務情報や個人情報をはじめとするデータについて、不正な取り扱いがされないこと

・限界
 万能薬は存在しない。
 経営者自身の不正、人間の判断誤りや不注意や悪意、環境の想定外の変化
 といったものには対処しきれない。またお金などリソース的な限界もある。



■通信

●S/MIME(エスマイム)
・Secure / Multipurpose Internet Mail Extensionsの略。
 電子メールの暗号化と署名に関する標準規格。
 公開鍵暗号と共通鍵暗号を組み合わせたハイブリッド方式を使っている。

・仕様
 - RSAが開発、IETFが変更管理
 - 仕様:RFC 5751がVersion 3.2、RFC 3851がVersion 3.1、RFC 2633がVersion 3

・機能
 認証、改竄防止、発信元の否認防止(デジタル署名)、機密保護(暗号化)

・S/MIME準備
 CAから鍵ペア、証明書の取得が必要。
 組織内認証局または、公的な認証局から、個別の鍵ペア/証明書の両方を入手する必要がある。
 署名用、暗号化用で、別の鍵ペア(および関連する証明書)を使うこともできる。

・他の電子署名
 S/MIME以外だと、PGP(Pretty Good Privacy)

・MIMEタイプ
 application/pkcs7-mime(smime-type "enveloped-data")

・鍵について
 本文の暗号化:送信先の人の公開鍵を使う
  ⇒ 理由:送信先の人だけが自身の秘密鍵で読める

 署名の暗号化:送信元の人の秘密鍵を使う
  ⇒ 理由:送信先の人が、送信元の人の公開鍵だけを使い検証できる
  ⇒ 復号できなかった場合は、改ざんされていたり、メッセージの送信元があやしい

 上記の大前提:公開鍵の正当性。公開鍵が正しいこと、という前提が成立しないと、検証はできない。
  ⇒ これが一番大事だが、この担保は認証局がすることになる。
  ⇒ 一方、PGPだとこの部分は「Web-of-trust(信用の輪)」の考えで担保される
  ⇒ S/MIMEは、ここが肝であるが、それゆえに費用発生がネックで広まらない。
    なお、S/MIMEを使えない電子メールクライアントもある。

・課題
 - ウイルスやマルウェアなどへの対策
  上記のような仕組みから、お互いの鍵を使って端点の間で暗号化されるが、
  それゆえに仮にウイルス・マルウェアなどが混入しても、復号化されるまで検出できない。
  途中で一度復号化して検査、という考えもありえなくはないが、それはそれでリスクであり悩ましい。

 - Webメールの署名問題
  署名は本人であることの検証に使う。これはWebメールの場合、
  Webメールサーバ上で署名の処理がされることになるので、
  「所有者唯一の制御下」から外れてしまうことになり、危険ではないのか。

 - メーリングリストとの相性問題
  デジタル署名は、MLで添付ファイル不許可になっていたら、
  相手に届けられない。拒否のエラーメールがサーバから送られてきたりする。

●SPF
・sender policy framework
 送信者偽称を防ぐ送信ドメイン認証技術の1つ。
 DNSを使用する仕組みで、既存システムに影響を与えないで導入できる。

・迷惑メールの特性とSPF
 - 送信元アドレス偽称が多い。これは、迷惑メール送信者特定を困難にするため。
 - SMTPの、送信者メールアドレス2種類が同一でなくてもよいことを利用してくる。
 - アドレスがある場所は、電子メールのFrom:ヘッダーと、SMTP通信でのMAIL FROM:コマンドの引数の2つ。
 - 任意のアドレスを指定可能なため、送信者の偽称が容易
 - SPFを使うと、メール受信時、SMTP通信の送信者であるはずのメールアドレス(エンベロープ送信者)
  のドメインから送られてきたものかどうかを確認できる。

・SPF
 - SPFは、IPアドレスベースの認証方式であり、DNSのSPFレコードを使用する。
 - クライアントからメールサーバにSMTPでメールを送信後、送信先メールサーバから
  送信元ドメインのDNSサーバにSPFレコード問合せを行い、MAIL FROMコマンドの引数である
  アドレスのドメインとの突合せをする。エンベロープの送信者アドレスを元に認証。
 - 送信元ドメインのDNSサーバのSPFレコードに記載されたIPアドレスリストに
  メール送信元のメールサーバのアドレスが含まれていれば、認証OKとなる
 - TXTリソースレコード(TXT RR)がSPFレコードとして使用されていることもある
  (SPFリソースレコードに非対応のDNSサーバやリゾルバが存在するので
   TXT RRを使うことも多い。両方ある場合にはSPF RRが優先されるらしい)
 - メールの送信側の準備はお手軽。DNS上でSPFレコードを公開するのみ。

・SPFレコード
 - バージョン 空白 定義(空白と定義は繰り返し可能)
  hoge.org. IN TXT "v=spf1 ip4:11.22.33.44 -all"
  のような記述。
 - バージョンは、「v=spf1」
 - 定義は、ディレクティブと修飾子から成る。ディレクティブはさらに、限定子と機構からなる。
  つまり、限定子と機構と修飾子で定義が書かれている
 - 修飾子はredirectとexpのみ。前者はリダイレクト先のドメインにて認証するときに使用。
  後者は、認証失敗時に使用するもので、引数のドメインのTXT RRの文字列を、認証失敗理由等で使う
 - 限定子は、それに続く機構(IPアドレス等)についての認証結果を指定するもので、
  プラス、マイナス、クエスチョンマーク、チルダの4つ記号のみ。
  このドメインの送信メールサーバとして認証するもの、しないもの、
  認証情報の非公開、公開するが失敗の可能性あり、の4つの意味に対応。
 - 機構は、認証対象のIPアドレス(送信元メールサーバ)とつき合わせるときの条件を記述。
  all、ip4:IPアドレス、mx:hoge.orgなど。CIDRやFQDNでの指定もできる

・SPF認証結果
 白黒はっきりしているのは2つ。
 - Pass:認証成功
 - Fail:送信元詐称の可能性が高い

 ほかは、即時での判断はできない。
 - None/Neutral:認証できなかった(SPF RR非公開)⇒ メールは通常どおりの扱い
 - SoftFail:上記のチルダでひっかかった場合なので黒ではないかもだが微妙
 - TempError:一時障害での認証失敗
 - PermError:DNSサーバ側でSPFレコード設定の誤りがあった場合など。
  ⇒ バージョン文字列のtypoなど、自動化やチェック機能がないとやってもおかしくない。

・課題
 - MLで転送など、認証時の送信元が、本来の送信元と違っている場合には、認証失敗となる。
  マイクロソフト社が提案のSender IDを使えば、ヘッダ上のアドレスを使うので転送問題は回避できる
 - Sender Rewrite Scheme ⇒ 転送時の問題に対処しようという試みだが広まらない。いろいろ改修大変



■その他

・CMS : Cryptographic Message Syntax
 暗号メッセージ構文。RFC 5652。
 任意のデジタルデータに対し、デジタル署名、メッセージダイジェスト、メッセージ認証、暗号化を行う。
 PEMに基づいたPKCS#7の構文に基づいている

・PKCS (Public-Key Cryptography Standards)
 公開鍵暗号標準のグループ。以下のようなものを含んでいるが、
 いくつかの標準化組織に巻き取られる方向である。
 #1:RSA暗号標準。暗号鍵、公開鍵、秘密鍵のフォーマット
 #3:Diffie-Hellman鍵共有標準。IKE(Internet Key Exchange )で使う暗号鍵交換で使われる
 #7:暗号メッセージ構文。PKI の下で、メッセージの署名、暗号化に使用
 
・PEM (Privacy-Enhanced Mail)

・DH鍵共有
 ディフィー・ヘルマン鍵共有(もしくは鍵交換ともいう)。
 事前に情報共有せずに、第三者が仲介しうる通信路上で、
 暗号鍵(共通鍵)を共有するプロトコル。
 鍵長は、2048bit未満はあまりよろしくない。
 年々、マシン性能の向上とともに短い鍵長は危険になる。

・CA: Certificate Authority
 認証局。パブリックCA、組織内認証局などがある

PCI DSS
 Payment Card Industry Data Security Standards
 国際クレジットカード会社5社で設立した組織の定めた、
 カードに関するグローバルなセキュリティ業界標準。

 以下のような要件が定められている
 - ネットワークの構築や維持(定期監視やテスト含む)に関する要件
 - カードデータについての保護の要件
 - 脆弱性管理、脅威からの保護
 - アクセス制御手法
 - 情報セキュリティポリシー整備

・他の送信ドメイン認証技術
 spfのほか、DKIM (Domain Keys Identified Mail)、Sender IDなどがある
関連記事
スポンサーサイト

コメントの投稿

非公開コメント

プロフィール

kr2

Author:kr2
ネコと音楽が好き。
CD紹介、技術ネタ
などの雑記帳。

カレンダー
10 | 2017/11 | 12
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 - -
月別アーカイブ
カテゴリー
ブログ内検索
RSSフィード
最近の記事
最近のコメント
最近のトラックバック
リンク
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。