ファジング

• 検査対象のソフトウェアに対して、機械的に生成した、問題を引き起こしそうな入力データ(ファズ)を与え、その応答や挙動を観察することで、脆弱性を見つける検査手法
• 専用のソフトウェアを使えば、検査対象のソフトウェアの開発者ではなくても比較的簡単にファジングを実施できるので、費用対効果が高い

マイコン

• マイクロコントローラの略
• CPU、メモリ、タイマ、割り込みコントローラ、シリアル通信デバイス、ADC(Analog to Digital Converter)、DAC(Digital to Analog Converter)などをワンチップに集積した半導体

ネットワークストレージ

• 磁気ディスク装置や磁気テープなどのストレージ(補助記憶装置)をネットワーク上に配置したもの
• DAS、NAS、SANなどの方式がある

キャズム

• ロジャーズがイノベーション理論の中で製品の購入層の変化があり、購入層が切り替わる際に断絶があると考えた
• 製品の購入層がアーリーアダプタからアーリーマジョリティ―に切り替わる際に乗り越えなければならない大きな断絶のこと
• キャズムを超えられなかった製品は、一般に普及することなく市場から退場する
• ムーアは、ハイテク製品におけるキャズムは大きいとしている
• 購入層の変化
  • イノベータ：新しいものを進んで購入する革新者
  • アーリーアダプタ：流行に敏感な初期採用者
  • (キャズム)
  • アーリーマジョリティ：比較的慎重な前期追従者
  • レイトマジョリティ：周囲の多数に追従する後期追従者
  • ラガード：新たなものに関心の薄い遅滞者

インシデント(情報セキュリティインシデント)

• 情報セキュリティを脅かす可能性が高い予期しない、または望まない事象(イベント)のこと
• サービスの停止や設備の故障、過負荷状態、人的なエラーなど

リスク対応

• リスクに対しては、リスクを分析・評価した結果、そのリスクに応じた対応策を講じる
• リスクへの対応戦略
  • マイナスのリスク(脅威)に対する対応戦略
  • エスカレーション
  • 回避
  • 転嫁・移転
  • 軽減・低減
  • 受容
• プラスのリスク(好機)に対する対応戦略
  • エスカレーション
  • 活用
  • 共有
  • 強化
  • 受容
• プラスのリスクとマイナスのリスクどちらにも用いる対応戦略
  • エスカレーション
  • 受容
• 回避
  • リスクと資産価値を比較した結果、コストに見合う利益がえられないばあいなど、資産ごと回避する
  • リスク事象の原因を取り除いたり、プロジェクト目標にリスクの影響を与えないために、プロジェクト計画を変更すること
  • リスクが大きいと評価されたシステムを廃止し、新たなセキュアなシステムの構築に資金を投入する
  • 例
    • 業務の廃止、資産の廃棄、など
    • リスクレベルが大きいと評価した情報システムを用いるサービスの提供をやめる
• 移転・移転
  • 資産の運用やセキュリティ対策の委託、情報化保険など、リスクを他者に移転する
  • リスクそのものを第三者へ移すこと
  • リスク自体は無くならない
  • リスクを引き受ける側にリスクの対価を支払う
  • 例
    • ハウジングサービスの利用、情報化保険の加入、など
    • リスクファイナンシング
      • リスクによってシステムが被害を受けた場合を想定して保険を掛けること
      • リスクの顕在化に伴う被害からの復旧にかかる費用を算定し、保険を掛ける
• 軽減・低減
  • 適切な管理策(コントロール)を採用することにより、リスクが発生する可能性やリスクが発生した場合の影響度を低減する
  • 管理策適用後のリスクレベルが受容できるリスク基準の範囲内に収まれば、残留リスクとして受容できることになる
  • リスクの発生確率と発生した場合の影響の大きさを、受容可能なレベルまで低下させること
  • リスクの発生前や兆候が見られた時点での早期の対応策の実施は、リスク発生に後に修復のための対策を講じるよりもはるかに効果がある
  • 例
    • セキュリティ技術の導入、入り口の施錠、スプリンクラーの設置、など
    • 情報システムのハードウェア構成を冗長にする
    • システム被害につながるリスクの発生を抑える対策に資金を投入する
    • リスクが顕在化した場合のシステム被害を小さくする設備に資金を投入する
• 受容
  • 識別されており、受容可能なリスクを意識的、客観的に受容する
  • リスクが顕在化したときは、その損害を受け入れる
  • リスクへの対策を何も行わず、リスクが発生した場合、そのリスクの発生の影響を甘受すること
  • 既知のリスクに応じた期間や予算、資源を賄えるだけのコンティンジェンシ―予備を設定する
  • コンティンジェンシ―予備は、受容するリスクのレベルをもとに算定した影響の大きさによって決められる
  • 例
    • 会社が損失額を負担する、など
    • リスクレベルが小さいので特別な対応はとらないという意思決定をする
• 活用
  • プラスのリスクを確実なものにするための対応をとること
• 共有
  • プラスのリスクの実行権限を第三者に割り当てること
• 強化
  • プラスのリスクの生じる確率を増加させたり、影響度合いを大きくするための策を講じること
• 個人情報の漏洩に関するリスク対応例
  • リスク回避
    • 収集済みの個人情報を消去し、新たな収集を禁止する
  • リスク保有(受容)
    • 個人情報の重要性と対策費用を勘案し、あえて対策をとらない
  • リスク低減
    • 個人情報の保管場所に外部の者が侵入できないように、入退室をより厳重に管理する
  • リスク移転
    • 個人情報を含む情報資産を外部のデータセンタに預託する

DNSサーバ

• インターネット上のDNSサーバは階層化されており、ある名前に対して情報がない場合は上位のDNSサーバに問い合わせる
• ルートネームサーバ
  • 最上位のDNSサーバ
• 階層構造の最下位に位置するネームサーバ以外は原則的に再起処理を行う
• DNSサーバを構成する3つの機能
  • スタブリゾルバ ( DNSクライアント 、 リゾルバ )
    • ユーザ側のホストからDNSサーバ（フルサービスリゾルバ）へ名前解決を依頼し（再帰問い合わせ）、必要な情報を取得するために使用されるユーザ側のホストで動作しているプログラム
  • フルサービスリゾルバ（キャッシュネームサーバ）
    • クライアントからの問い合わせに対して、名前解決が完了するまで問い合わせを繰り返すDNSサーバ
    • 一度名前解決したDNS情報をキャッシュとして再利用する
  • コンテンツサーバ
    • 独自ドメインの運営に必須のサーバ
    • 外部からの問い合わせに対してDNSサーバ自身が管理するDNS情報についてのみ回答し、名前解決できない場合には、ほかのDNSサーバに問い合わせをせずDNS情報なしの回答をする
• ネガティブキャッシュ
  • DNSサーバが名前解決に失敗した情報を一定期間保持するもの
  • 存在しないホストに対する無駄な名前解決処理を抑制することができる
• 複数ゾーンの管理
  • 個々のゾーンに対する名前のクエリー(問い合わせ)の頻度が低く、複数のゾーンを管理する必要がある場合には、単一のネームサーバによって複数のゾーンを管理することができる
  • これを実現するためには、それぞれのゾーンの情報を記述したゾーンファイルを用意し、ネームサーバの設定ファイル中にゾーンの記述を列記する
  • これを応用して1つのネームサーバをあるゾーンに関してはプライマリネームサーバ(マスタサーバ)、別のゾーンに関してはセカンダリネームサーバ(スレーブサーバ)として動作させることも可能
  • 複数のゾーンを混在させて管理する技術は、ドメインホスティングなどで利用される
• 外部向けDNS情報と内部向けDNS情報
  • セキュリティ上の理由などで、イントラネット内部で利用するDNS情報と外部に提供するDNS情報に差をつけて運用する(Split DNS)場合の方法
  • 完全分離型
    • 外部に公開するDNSサーバと内部で利用するDNSサーバを独立して設置する方法
      • 内部DNSと外部DNSは異なるゾーンファイル及び設定を利用して構成する
      • イントラネット内部の情報は内部DNS上にのみ設定し、外部DNSと内部DNSの間にファイアウォールやNAT装置を配置することにより、インターネット上には外部DNSのみを公開する
      • 内部DNS上にはインターネットに関する情報はないが、外部DNSに向けてクエリーのフォワード(転送)を行うように設定することで名前の解決を可能にしている
  • アクセス分離型
    • NATやファイアウォール装置上で複数のDNSサーバプロセスを動作させ、外部DNSおよび内部DNSと同等の役割をもたせる手法
    • サーバプロセスが応答するインタフェースやIPアドレスを外部と内部のそれぞれに分けることで実現する
  • クライアントのアドレスによる振り分け
    • 設定ファイルにおいて2つ以上の異なるviewを設定することで、問い合わせ元のIPアドレスによって応答の内容を振り分け、内部と外部に異なるDNS情報を提供する
• ダイナミックアップデート
  • DNSのゾーン情報をクライアントコンピュータやDHCPサーバで動的に更新すること
  • 通常はダイナミックアップデートが実行されないように設定されているが、DHCP環境においてクライアントに割り当てるIPアドレスが常に変化する場合は名前とIPアドレスの対応を動的に更新する必要があるため、ダイナミックアップデートの実行を許可しなければならない
• DNSサーバのセキュリティ
  • 情報の漏洩
    • BINDのバージョン情報の取得
      • BINDに対してdigコマンドを利用してDNSのクエリーを発行し、BINDプログラムのバージョン情報を知ることができる
      • 対処:バージョン情報を変更する
    • ゾーン転送
      • 不正なゾーン転送を利用してドメイン内に登録されているホストの各種情報(ネットワーク構成やサーバの構成など)を調べることができる
      • 対処:ゾーン転送を許可するホストを制限する
  • 情報の改ざん、不正な情報の挿入
    • ダイナミックアップデート
      • ダイナミックアップデートの実行が許可されていると、ダイナミックアップデートを実行して不正な更新情報を送りつけることができる
      • 対処:特定のネットワークからの更新要求のみを受け付けるようにする
    • 偽装DNSリプライの挿入
      • 正規のDNSサーバがネットワーク的に遠い位置に存在したり、動作していない、あるいはDos攻撃等で機能していない場合に、クエリーを発行したクライアントの送信元および宛先IPアドレスとUDPポートおよびクエリーIDを取得して当該クライアントに対して正規のDNSになりすまし不正なリプライを応答する
      • 対処:根本的な解決策は無いが、BIND9.1では同時に行われた問い合わせを並行して処理しないためWindowsのDNSよりはセキュリティが高いと言われている
    • DNSキャッシュポイズニング
      • 再帰的な問い合わせを行う際に対象となるクライアントから攻撃者が管理するDNSサーバへ問い合わせを行わせ、そのリプライに不正なレコードを紛れ込ませる
      • 対処:外部からの再帰的な問い合わせを禁止する
• DNSサーバの設定ファイル(BINDの場合)
  • コンフィギュレーションファイル(named.conf)
    • BINDの実行プログラムが読み込むファイルで、ルートキャッシュファイル、ループバックファイル、正引きゾーンファイル、逆引きゾーンファイルのファイル名を記述する
    • 問い合わせを許可するネットワークを限定する
    • ゾーン転送を許可するネットワークを限定する
    • ログにどのような情報を記録するか指定する
  • ルートキャッシュファイル
    • ルートネームサーバのIPアドレスとホスト名を記述する
    • 自ホストを表すIPアドレス127.0.0.1からホスト名を逆引きできるようにする
  • ループバックファイル
    • ローカルホストのループバックアドレスを設定するファイル
  • 正引きゾーンファイル
    • ホスト名からIPアドレスを探索するための設定ファイル
  • 逆引きゾーンファイル
    • IPアドレスからホスト名を探索するための設定ファイル
    • ".in-addr.arpa"という特別な空間が使われている
    • IPアドレスの記述は、IPアドレスを逆にして、逆引きようのドメイン".in-addr.arpa"を付加する
  • ゾーンファイルのレコード
    • SOAレコード：ドメイン（ゾーン）に関する情報として、DNSサーバ名、管理者、シリアル番号、リフレッシュ間隔、リトライ間隔、期限切れまでの時間、ネガティブキャッシュを指定する
    • NSレコード：ドメインのネームサーバ名（プライマリ/セカンダリ）を指定する
    • Aレコード：ホスト名とそれに対応するIPv4のIPアドレスを指定する（正引き）
    • ホスト名からIPアドレスへの対応を示す
    • AAAA：レコード：ホスト名とそれに対応するIPv6のIPアドレスを指定する（正引き）
    • PTRレコード：IPアドレスとそれに対応するホスト名を指定する（逆引き）
    • CNAMEレコード：ホストの別名（エイリアス）を指定する
    • MXレコード：ドメインのメールサーバ名を指定する
    • TXTレコード：ホストの情報やスパム対策のための送信ドメインの認証情報を記述する
  • DNSの権限委譲によってサブドメインを作成する
    • ゾーンファイルに定義する
    • 必要に応じて自由に作成でき、JPRSなどへの届け出は不要
    • 親ドメインのゾーンファイルに対してサブドメインのDNSサーバに関するNSレコード、Aレコードを記述する
    • サブドメインのゾーンファイルに対してサブドメインのDNSサーバに関するNSレコードを記述する
    • サブドメインに属するホストは親ドメインとは異なるサブネットワークに切り分ける必要はない
  • DNSラウンドロビン
    • 1つのホスト名に対して複数のIPアドレスを割り当てる機能
    • 複数のサーバによる負荷分散を行う
    • DNSサーバのゾーンファイルにラウンドロビンさせるサーバの数だけAレコードを記述する
    • DNSにおいて、一つのサーバ名に対して複数のサーバのIPアドレスを割り当てることによって実現する
  • ダイナミックDNS
    • IXFR ( incremental zone transfer )
      • 変更されたレコード情報だけをゾーン転送する機能
    • DNS NOTIFY
      • ダイナミックDNSにおいて、プライマリDNSサーバからセカンダリDNSサーバにゾーン情報の変更が合った旨を通知することによって、リフレッシュ時間の経過を待たずにセカンダリDNSサーバからプライマリDNSサーバへゾーン転送を要求させる機能

プロダクトポートフォリオマネジメント(PPM ； Products Portfolio Management ； 事業ポートフォリオ分析，マトリックス表を用いたポートフォリオ類型)

• 市場の成長率と占有率をもとに、企業の製品やサービスを分類し、どの製品に経営資源を投下すべきか、将来的に利益が見込めない事業はどれかといった分析を行う手法
• 市場成長率と相対的市場シェアから、市場と企業の関係を分析し、自社製品や事業についての最適な資源配分方針を求めるための手法
• 市場の魅力度と市場内での自社の地位を基に、企業に製品やサービスを分類し、どの分野に経営資源を投資し、利益を拐取すべきかを検討するためのモデル
• 事業計画や競争優位性を分析する手法でマトリックス図を用いて表現する
• 多用な事業に関して、経営資源配分のガイドラインを提供し、その優先順位の決定に役立つ手法
• 目標を設定し、資源配分の優先順位を設定するための基礎として、自らの置かれた立場を評価する手法で、多様な事業に経営資源をどう配分するのかのガイドライン、優先順の決定に役立つ
• 目標を設定し、資源配分の優先順位を設定するための基礎として、自らの置かれた立場を表明する
• 横軸には事業の強みを、縦軸には事業の魅力度をとって様々な分析を行う
• プロダクトポートフォリオマネジメント(PPM)において、投資用の資金源と位置づけられる事業
  • 市場成長率が低く、相対的市場占有率が高い事業
• 市場の成長率と占有率をもとに、企業の事業を4種類に分類し、経営資源を投下する事業や今後利益が見込めない事業などを分析する
• 明らかになるもの
  • 保有する事業の成長性と収益性
• 製品の市場占有率と市場成長率から、企業がそれぞれの事業に対する経営資源の最適配分を意思決定する
• 戦略的観点から経営資源の配分が最も効率的・効果的となる製品・事業相互の組み合わせを決定するための経営分析・管理手法
• 自社の事業や製品を外部要素(市場成長率)と内部要素(市場シェア)で評価し、対応策を決定する
• 製品の相対的市場占有率と市場成長率から、企業がそれぞれの事業に対する経常資源の最適配分を意思決定する
• 市場の成長性と占有率の観点から各事業の位置付けを分析する
• 製品を、市場の魅力度と自社の強みの2軸を用いて、花形、金のなる木、問題児、負け犬の4象限のマトリックスに分類する
  • 問題児
    • 事業としての魅力はあり、資金投下を行えば、将来の資金供給現になる可能性がある
    • 市場成長率は高いが、市場占有率が低い製品である。長期的な将来性を見込むことはできるが、資金創出効果の大きさは分からない
  • 負け犬
    • 事業を継続させていくための資金透過の必要性は低く、将来的には撤退を考えざるを得ない
    • 市場成長率、市場占有率ともに低い製品である。資金創出効果は小さく、資金流出量も少ない
  • 金のなる木
    • 投資用の資金源と位置づけられる事業
    • 投資用の資金源、市場成長率が低く、市場占有率が高い事業
    • 現在は資金の主たる供給源の役割を果たしており、新たに資金を投下すべきではない
    • 市場成長率が低く、相対的市場占有率が高い事業
    • 市場成長率は低いが、市場占有率は高い製品である。資金創出効果が大きく、企業の支柱となる資金源
  • 花形
    • 現在は大きな資金の流入をもたらしているが、同時に将来にわたって資金の投下も必要である
    • 市場成長率、市場占有率ともに高い製品であるが、成長にともなう投資も必要とするので、資金創出効果は大きいとは限らない
    • 市場成長率、市場占有率ともに高い製品である。成長に伴う投資も必要とするので、資金創出効果は大きいとは限らない

デシジョンツリー

• 関連づけられた意思決定の順序と、ある選択肢を選んだ時に期待される結果を記述する図
• 可能な選択はツリー状に描かれ、左側のリスクの決定から始まり、右に向かって選択肢が伸びていく
• リスクの確率と個々の選択肢の決定によってもたらされる費用、期待値を数値化する
• とりうる選択肢や起こりうるシナリオすべてを木形の図で洗い出し、それぞれの選択肢の期待値を比較検討した上で、実際にとるべき選択肢を決定する手法

アフィリエイトマーケティング(affiliate marketing)

• バナーやテキストの広告を複数のウェブサイトに掲載し、訪問者とそれに対する収益をシェアする形式のインターネットマーケティング
• Webサイトの閲覧者が掲載広告のリンク先であるECサイトで商品を購入した場合、広告主からそのWebサイト運営者に成果報酬を支払う仕組み
• ECサイトが販売する商品を自分のWebページで紹介し、それを見た人が商品を購入した場合、購入額に応じた報酬をECサイトから受け取る仕組み
• インターネット上で成果報酬型広告の仕組みを用いるマーケティング手法
• 自分のWebサイトやブログに企業へのリンクを掲載し、他者がこれらのリンクを経由して商品を購入したときに、企業が紹介料を支払うこと
• Webサイトの閲覧者が掲載広告のリンク先であるECサイトで商品を購入した場合、広告主からそのWebサイト運営者に成果報酬を支払う仕組み
• Webページに掲載した広告が契機となって商品が購入された場合、売主から成功報酬が得られる仕組み
• Webサイトの閲覧者が掲載広告からリンク先のECサイトで商品を購入した場合、広告主からそのWebサイト運営者に広告報酬を支払うこと

XBRL(eXtensible Business Reporting Language)

• XMLをベースにした財務諸表などのビジネスレポートを電子化するための(マークアップ)言語
• 財務報告用の情報の作成・流通・利用ができるように標準化した言語であり、適用業務パッケージやプラットフォームに依存せずに財務情報の利用が可能となる
• 企業の財務情報を記述するための言語及び規約
• XMLベースの言語であり、ソフトウェアやプラットフォームに依存しないため、財務情報を円滑に流通・利用できるようになる
• 各種財務報告用の情報を作成・流通・利用できるように標準化されたXMLベースの言語
• 文書情報やデータの構造を記述するためのマークアップ言語であるXMLを、財務情報の交換に応用したデータ記述言語
• 財務報告用の情報の作成・流通・利用ができるように標準化した規約であり、適用業務パッケージやプラットフォームに依存せずに財務情報の利用が可能となる
• XBRLによって、決算などに伴う集計、法定書類の自動化を容易にする
• XBRLによって表現される勘定科目体系は、個別に定義することが可能
• 企業外部向け財務会計情報の開示に利用するだけでなく、企業内部向けの管理会計情報としても利用できる
• XBRLで主要な取扱いの対象とされている情報
  • 企業の財務情報

TLO(Technology Licensing Organization；技術移転機関)

• 特許性や市場性がある大学の研究成果を譲り受けて特許化し、最適な企業への実施許諾を行って技術移転を支援する機関
• 産学の仲介役を果たす組織
• 承認又は認定された事業者の役割
  • 大学の研究成果の特許化及び企業への技術移転の支援を行い、産学の仲介役を果たす
• 大学の研究成果の特許化及び企業への技術転移の促進
• TLOは産学の仲介役として、特許の実施許諾料などの収益を大学の新たな研究資金として還元する
• TLO法
  • 大学から企業への技術移転に関するTLOの活動を支援するために制定された法律

RPA(Robotic Process Automation)

• 自社の経営課題である人手不足の解消などを目標とした業務革新を進めるために活用する
• 業務システムなどのデータ入力、照合のような標準化された定型作業を、事務職員の代わりにソフトウェアで自動的に処理する
• ホワイトカラーが行っていた事務処理などの定型業務をロボットと呼ばれるソフトウェアに代行させ、自動化すること
• RPAの導入によって、人間が行うよりも速く、正確に事務処理を行うことができる
• 社員が面倒な事務処理から解放され、他の業務に時間を使うことができるため、生産性を向上させることができる
• コスト削減や人材不足解消といったメリットがある
• AIや機械学習といった技術を組み込むことで、業務のより高度な自動化が期待されている
• ホワイトカラーの単純な間接作業を、ルールエンジンや認知技術などを活用して代行するソフトウェア
• 自社の経営課題である人手不足の解消などを目標とした業務革新を進めるために活用する
• ホワイトカラーが実施してきた定型的なデスクワークをPC内のソフトウェアで作られたロボットに代行させて自動化する技術
• RPAで使われるロボットは、工場などで稼働しているハードウェアの産業用ロボットに対して、ソフトウェアロボットと呼ばれる
• 業務が効率化され、生産性が高まるため、人手不足解消や働き方改革につながることが期待できる
• 定型的なデスクワークをロボットに代行させる技術
• ホワイトカラーが実施してきた定型的なデスクワークをPC内のソフトウェアで作られたロボットに代行させて自動化する技術
• RPAで使われるロボットは、工場などで稼働しているハードウェアの産業用ロボットに対して、ソフトウェアロボットと呼ばれる
• 業務が効率化され、生産性が高まるため、人手不足解消や働き方改革につながることが期待できる
• 例
  • 業務システムのデータ入力や照合
    • ユーザの操作を認識し、帳票作成やメール送信などのワークフローと組み合わせて、業務プロセスを自動化する
  • 事務職員が人手で行っていた定型的かつ大量のコピー＆ペースト作業をソフトウェアによって自動化し、作業時間の短縮と作業制度の向上を実現させた
  • 業務システムなどのデータ入力、照合のような標準化された定型作業を、事務職員の代わりにソフトウェアで自動的に処理する

JIS Q 27000:2014(情報セキュリティマネジメントシステム―用語)

• ISMS(Information Security Management System、情報セキュリティマネジメントシステム)ファミリー規格の概要で各規格において使用される用語等について規定した規格
• 情報セキュリティ
  • 主に機密性、完全性、可用性の三つの特性を維持すること
• 情報セキュリティリスク
  • リスク分析
    • リスクの特質を理解し、リスクレベルを決定するプロセス
  • リスク対応
    • 適切な管理策を採用し、リスクを修正するプロセス
  • リスク評価
    • リスクが受容可能か又は許容可能かを決定するために、リスク及びその大きさをリスク基準と比較するプロセス
    • リスクが需要可能か否かを決定するために、リスク分析の結果をリスク基準と比較するプロセス
    • リスクとその大きさが受容可能か否かを決定するために、リスク分析の結果をリスク基準と比較するプロセス
  • リスク特定
    • リスクを発見、認識及び記述するプロセスのことであり、リスク源、事象、それらの原因及び起こり得る結果の特定が含まれる
  • リスクレベル
    • 結果とその起こりやすさの組合せとして表現される、リスクの大きさ
  • 脆弱性
    • 脅威によって付け込まれる可能性のある、資産又は管理策の弱点
• 情報セキュリティインシデント
  • 単独又は一連の情報セキュリティ事象は、情報セキュリティインシデントに分類される
• 不適合への対応
  • 是正措置
    • 不適合の原因を除去し、再発を防止するための処置
    • 不適合が発生した場合にその原因を除去し、再発を防止するためのもの
• 情報セキュリティの特性
  • 機密性
    • 認可されていない個人、エンティティ又はプロセスに対す手、情報を使用させず、また、開示しないという特性
  • 可用性
    • 認可されたエンティティが要求したとき、アクセスおよび使用が可能であるという特性
  • 否認防止の特性
    • ある利用者がシステムを利用したという事実を証明可能にする
  • 真正性
    • エンティティは、それが主張するとおりのものであるという特性
  • 信頼性
    • 意図する行動と結果とが一貫しているという特性
• トップマネジメント
  • 組織を指揮し、管理する人々の集まりとして複数名で構成されていてもよい
• リスク所有者
  • リスクを運用管理することについて、アカウンタビリティ及び権限をもつ人または主体

負荷分散システム(ロードバランシングシステム)

• 複数のサーバが処理を分担することによって、サーバ1台当たりの負荷を軽減する方式であり、クラスタリングの一種と考えることもできる
• 負荷分散システムでは、サーバ群に到着した処理要求をいずれか1台のサーバに振り分けるために負荷分散装置(ロードバランサ)を設置する場合が多い
• 負荷分散装置の機能
  • 負荷分散機能
    • 複数のサーバに処理を振り分ける機能
  • セッション維持機能
    • 同じサーバに処理を振り分ける機能
  • サーバ監視機能
    • サーバの稼働状態を監視し、停止したサーバを振り分け先から除外する機能
• 処理を振り分ける際には、特定のサーバがボトルネックとならないよう、適切な振分けアルゴリズムを選択する必要がある
• サーバの処理性能が大幅に異なっていたり、処理要求ごとに負荷が大きく異なったりするような場合、振分けアルゴリズムを選択する必要がある
  • ラウンドロビン方式
    • 負荷分散対象のサーバに、順番に処理を振り分ける
    • 全てのサーバの処理能力や処理ごとの負荷がほぼ等しい場合に有効
  • 加重ラウンドロビン方式
    • 負荷分散対象のサーバに、決められた比率にしたがって順番に処理を振り分ける
  • 最小クライアント方式
    • クライアント接続数が最も少ないサーバに処理を振り分ける
  • 最小負荷方式
    • インストールされたエージェントソフトウェアから通知されるCPU負荷が最も小さなサーバに処理を振り分ける
  • 最小コネクション方式
    • 処理中のコネクションが最も少ないサーバに処理を振り分ける
  • 最小応答時間
    • 応答時間が最も短いサーバに処理を振り分ける
• 特徴
  • システム全体を効率よく運用するための運用管理が複雑になることが多い
  • 同一の処理機能を持った複数のコンピュータによって、端末や回線の制御、またはデータの処理を分担して実行するシステム
• 垂直分散システム(垂直機能分散システム)
  • 一連の処理を複数の階層に分割し、その階層に対応するシステムが分散して処理を行う
  • クライアントとサーバの関係のように、プロセッサ間に階層又は従属関係が存在する
  • 例）営業所内のデータ集計処理は各営業所に設置されたコンピュータで実行し、企業全体のデータ集計処理は本社に設置されたコンピュータで実行する
• 分散処理システムを構築する際のネットワーク透過性
  • 規模透過性
  • ＯＳやアプリケーションの構成に影響を与えることなくシステムの規模を変更できること
  • 性能透過性
  • システムの再構築を可能にすること
  • 並行透過性
  • 複数の作業が並行して行われていることが意識されないこと
  • アクセス透過性
  • ネットワークに接続されている異なる種類の資源に対して、同一方法でアクセスできること
  • 遠隔地にある資源を、遠隔地での処理方式を知らなくても、手元にある資源と同じ操作で利用できる
  • 複写（複製）透過性
  • システムの信頼性や性能の向上のためにファイルの複製物を持つこと
  • 位置透過性
  • ネットワークに接続されている資源に対して、その存在位置を意識することなくアクセスできること
  • 経路透過性
  • 機種透過性
  • 障害透過性
  • ハードウェア、ソフトウェアに障害が発生しても、障害を意識することなく利用できること
  • 移動(移送)透過性
  • オブジェクトの移動が意識されないこと
• タンデムシステム ( tandem system )
  • 複数のCPUを直列につなぐことで負荷分散するシステム構成
• ロードシェアシステム ( load share system )
  • ロードバランサなどを用いて複数の処理系に処理を分散させることで処理効率や信頼性の向上を図るシステム構成

IPアドレス

• IPアドレス
  • IPネットワークで使われるアドレス
  • ルーティングをしたり、ノードを特定するために使われる
  • IPv4では32桁の2進数
  • 人が読む場合には10進数で表記する
  • ネットワークアドレス
    • ネットワークそのものに付与される番号
    • 同じネットワークに所属しているノードのネットワークアドレスは必ず同一になる
  • ホストアドレス
    • ネットワーク内でノードを識別するための番号
  • クラス
    • IPアドレスのどこまでがネットワークアドレスで、どこまでからがホストアドレスかを示すもの
    • 現在ではサブネットマスクを使う方法に移行した
    • クラスA
      • ネットワークアドレス8ビット、ホストアドレス24ビットで16777216個のホストアドレスを用意できる
      • ネットワークの先頭ビットが0
    • クラスB
      • ネットワークアドレス16ビット、ホストアドレス16ビットで65534個のホストアドレスを用意できる
      • ネットワークアドレスの先頭ビットが10
    • クラスC
      • ネットワークアドレス24ビット、ホストアドレス8ビットで254個のホストアドレスを用意できる
      • ネットワークアドレスの先頭ビットが110
    • クラスD
      • IPマルチキャストで使うアドレス
      • 先頭4ビットが1110
  • サブネットマスク
    • IPアドレスのどの位置でも、ネットワークアドレスとホストアドレスを区切れるようにした技術
    • ネットワークアドレス部に1、ホストアドレス部に0を立てて、IPアドレスとセットで使う
    • どこで区切っても良いので、クラスレスサブネットマスクとも言う
• IP通信
  • ユニキャスト
    • 通常行われる1対1の通信
  • ブロードキャスト
    • ネットワーク内の全てのノードに対して行う通信
    • ネットワークアドレスを指定して送信するので、個々のノードのIPアドレスを知らなくても送信できる
    • 通信帯域を圧迫する
  • マルチキャスト
    • 複数の端末にパケットを送信する場合、同じ経路を通る箇所ではパケットを一つにまとめる
    • グループに所属しているノードにあてた通信
    • IGMPというプロトコルを使用する
    • ルータがパケットを複製するので、伝送路を流れるパケットを一つにできるメリットがある

パスワードクラック

• 何通りものパスワードを繰り返し試してパスワードを破る行為
• 他人のパスワード(暗証番号)を探り当てること
• ワンタイムパスワード方式、バイオメトリック認証システムなど、パスワードクラックが困難な認証システムにするのが確実な対策手段であり、従来の固定式パスワードを用いる場合にはアカウントのロックアウト設定が有効な対策手段となる
• パスワードを試す方法には、推測によるもの、辞書ファイルを用いたもの、総当たりによるもの(ブルートフォース攻撃)などがある
• レインボー攻撃(レインボーテーブルを用いたパスワードクラック)
  • レインボーテーブル
    • パスワードと事前算出したハッシュ値との対応表
  • 方法
    • ハッシュ値から平文を得るためのアルゴリズムで生成したハッシュ値と平文の対応表を用いてパスワードクラックする
    • 平文のパスワードとハッシュ値をチェーンによって管理するテーブルを準備しておき、それを用いて、不正に入手したハッシュ値からパスワードを解読する
  • 対策
    • ソルトを用いる
      • ソルト
        • パスワードからハッシュ値を求める際にパスワードに付加する文字列
        • ユーザごとにランダムな文字列が設定されているので同じパスワードであってもユーザごとに異なるハッシュ値が生成される
• パスワードリスト攻撃
  • 何らかの方法で事前に利用者IDと平文のパスワードのリストを入手しておき、複数のシステム間で使い回されているりよしゃIDとパスワードの組を狙って、ログインを試行する
  • あるサイトから不正に入手したユーザIDとパスワードのリストを流用し、他の会員向けサイトへのログインを指向する手口
  • 利用者の多くが複数のサイトで同一のユーザIDとパスワードを使いまわしている状況を利用している
  • ユーザIDとパスワードは利用者のPCからではなく、会員向けサービスを提供しているサイトのサーバから盗み取られる
  • 対策
    • 利用しているサービスで異なるパスワードを設定する
• 辞書攻撃
  • 方法
    • パスワードによく使われる文字列を集めた辞書を使う
    • パスワードに使われそうな文字列が大量に登録されたファイル(辞書ファイル)を用いて順次試していく方式
    • 一般的な辞書に載っている英単語や情報システム関連の業務で用いられることが多い文字列(sys、tempなど)をパスワードにしている場合、この手法によって破られる可能性が高まる
    • オンライン攻撃ではそれほど多くのパターンを試すことができないためオフライン攻撃で用いられることが多い
    • パスワードとして利用されそうな単語を網羅した辞書データを用いて、パスワードを解析する
  • 対策
    • 推測しやすい言葉(辞書に載っている単語、生年月日などの個人情報など)をパスワードにしない
    • 推定されにくいパスワードを設定する
• ブルートフォース攻撃(総当たり攻撃)
  • 方法
    • パスワードに成り得る文字列の全てを用いて、総当たりでログインを試行する
    • 考えられる全てのパスワードの組合せを試す
    • 時間はかかるが必ずパスワードにたどり着く
    • 特定の文字数、文字種で設定され得るすべての組合せを試す方式
    • パスワード長が短く、文字種が少ない場合、この方法によって破られる可能性が高まる
    • オンライン攻撃ではそれほど多くのパターンを試すことができないためオフライン攻撃で用いられることが多い
    • 可能性がある文字のあらゆる組合せをパスワードとしてログインを試みる
    • 与えられた1組の平文と暗号文に対し、総当りで鍵を割り出す
    • 暗号解読のための攻撃法で、与えられた平文と暗号文の組に対して鍵を総当りで検索して解読を試みる
    • 文字を組み合わせてあらゆるパスワードでログインを何度も試みる
    • 与えられた1組の平文と暗号文の鍵候補を総当りで解読を試みる
    • 可能性のある文字のあらゆる組合せのパスワードでログインを試みる
    • 1組の平文と暗号文が与えられたとき、全ての鍵候補を1つずつ試して鍵を見つけ出す
  • 対策
    • パスワードを長くする、使う文字種類を増やすなどクラッカーが試さなければならない組合せを多くする
    • 頻繁に変更する
    • ログインの失敗をチェックして検知する
    • ログインの試行回数に制限を設ける
• リバースブルートフォース攻撃
  • パスワードを固定して何通りものユーザIDの組合せを指向する手法
• スニッフィング
  • 方法
    • パケットを盗聴する
  • 対策
    • パスワードを暗号化して送信する

無線LANアクセスポイントの識別

• SSID(Service Set IDentifie)サービスセット識別子
  • 最長32オクテットのネットワーク識別子であり、接続するアクセスポイントの選択に用いられる
  • SSIDの値を「ANY」または空白にすると任意のAPを使えるため、SSIDだけではAPの不正使用は防げない
  • 1つのステーションが複数のAPと通信できる状態にあるとき、このステーションが特定のAPだけを使うようにすることができる
  • APが定期的に送信するビーコンで自分のSSIDを周知することがあるので、そのビーコンから取り出したSSIDをステーションに設定すればAPを利用できるようになる
• ESSID(Extended SSID)拡張SSID
  • SSIDを拡張したもの
  • 最長32オクテットのホスト識別子であり、ネットワーク上で一意である
  • 最大32文字の英数字で表されるネットワーク識別子であり、接続するアクセスポイントの選択に用いられる
  • 最大32文字までの英数字が設定でき、複数のアクセスポイントを設置したネットワークに対しても使用できる、無線LANのネットワークを識別するもの
  • ビーコンフレームの中にESSIDが含まれているため、モニタリングツールで盗聴できる
  • ESSIDステルス機能
    • アクセスポイントのセキュリティを高めるためにESSIDの発信を行わない機能
• BSSID(Basic Service Set Identifier)
  • 48ビットのネットワーク識別子であり、アクセスポイントのMACアドレスと一致する

マルチプロセッサ

• 処理速度の向上のためにプロセッサを複数、効率的に使う技術
• 複数のプロセッサを一台のコンピュータに組み込むことによって性能を向上させる技術
• マルチプロセッサでは通常の処理に加えて各プロセッサ間での命令の振り分け、同期制御などが生じるため、プロセッサ数に完全に比例した性能を得ることはできない
• 一つのシステム上で複数のCPUを動作させる方式には、複数のプロセッサがメモリの一部を共有する密結合構成と、それぞれのプロセッサが専用のメモリをもち、プロセッサ間のデータ共有は通信によって行う疎結合構成とがある
• 密結合構成
  • 複数のプロセッサが同じメモリにアクセスしてデータを共有する
  • 複数の同種のプロセッサが主記憶を共有し、単一のOSで制御されることによって処理能力を高めるコンピュータシステムの構成
  • 複数のプロセッサが主記憶を共用し、単一のOSで制御される
  • システム内のタスクは、基本的にどのプロセッサでも実行できるので、細かい単位で負荷を分散することで処理能力を向上させる
  • 密結合マルチプロセッサ
  • 各タスクはどのプロセッサでも実行できるのでタスク間で同期を取る機能が必要になる
  • シングルプロセッサシステムの性能と比較したとき、主記憶のアクセスに対する排他制御のため、密結合マルチプロセッサ1台あたりの性能が低下する
  • 密結合マルチプロセッサの性能が、1台当りのプロセッサの性能とプロセッサ数の積に等しくならない要因
  • 主記憶へのアクセスの競合
  • 共有メモリ方式
    • 複数のプロセッサがすべてのメモリ空間を共有する方式
    • それぞれのプロセッサが直接メモリにアクセスできるため、アクセス自体は高速に行えるが、同時にメモリアクセスが発生した場合には順番待ちが発生する
    • メモリアクセスの競合を防ぐため、各プロセッサにそれぞれキャッシュメモリを持たせる構成も用いられる
  • デュアルポートメモリ(DPRAM)方式
    • 共有メモリ方式では必要なバスの調停回路が不要であるため、回路構成を簡単にすることができる
• 疎結合構成
  • それぞれのプロセッサが専用のメモリをもち、プロセッサ間でのデータ共有は通信によって行う方法
  • 主記憶を共有せずにプロセッサごとに主記憶を所有し、プロセッサ間は高速なネットワークで結合する
  • 疎結合マルチプロセッサ
  • 分散メモリ方式
    • 独立したコンピュータをネットワークで接続し、メッセージを送信することによって他のプロセッサのメモリにアクセスする方式
    • エンベデッドシステムでは、プロセッサ間でシリアル通信などを用いてデータを共有する
• メモリの構成による分類
  • 共有メモリ型
    • UMA(Uniform Memory Access)
    • 全てのプロセッサから共有メモリへのメモリアクセス時間が同等なマルチプロセッサアーキテクチャ
    • NUMA(Non-Uniform Memory Access)
    • 複数のプロセッサから共有メモリへのアクセス時間が、メモリ領域とプロセッサに依存して均一でないアーキテクチャ
    • COMA(Cache Only Memory Architecture)
    • 各プロセッサのローカルメモリをキャッシュとして扱い、大きな共有メモリ領域を提供するアーキテクチャ
  • 分散メモリ型
    • NORA(No Remote Memory Access model)
    • マルチプロセッサコンピュータで共有メモリを持たず、プロセッサ間はメッセージで交信を行う
• プロセッサの種類による分類
  • 均質(Homo)
    • 命令セットや性能が同じプロセッサで構成されているもの
    • 動的負荷分散のために使用される
  • 非均質(Hetero)
    • 命令セットや性能が同じプロセッサで構成されていないもの
    • 解決しようとする問題に最適なアーキテクチャの構成にすることが可能
    • Homoよりも複雑になる傾向がある

RASIS(Reliability,Availability,Serviceability,Integrity,Security)

• コンピュータシステムの高信頼化技術の呼び名
• 信頼性(Reliability :リライアビリティ)
  • 故障しにくいこと
  • 要求された機能を、規定された期間実行する能力
  • 数値化の尺度
    • $MTBF(平均故障間隔)=\cfrac{1}{λ}　(λ：故障率)$
      • 故障と故障の間の平均時間
      • 連続して問題なく使える時間を示す
      • 大きいほど故障しないシステム
• 可用性( Availability :アベイラビリティ ）
  • 高い稼働率を維持できること
  • コンピュータシステムを必要に応じていつでも使用できる状態に維持する
  • 要求されたサービスを、提供し続ける能力
  • 使いたいときにシステムが使える状態にある割合
  • 数値化の尺度
    • $稼働率=\cfrac{MTBF}{MTBF+MTTR}$
• 保守性( Serviceability :サービサビリティ)
  • 障害が発生した場合に迅速に復旧できること
  • 故障発生時にどのくらいで修理できるかという意味
  • 数値化する尺度
    • $MTTR(平均修理時間)=\cfrac{1}{μ}　(μ：修理率)$
      • 小さいほどよい
      • 機器のユニット化やホットスワップなどでMTTRを小さくできる
• 保全性( Integrity :インテグリティ)
  • データが矛盾を起こさずに一貫性を保っていること
  • 情報の一貫性を確保する能力
  • データ改ざんや不整合、データが失われたりする度合い
  • プログラムの瑕疵や過負荷時の誤動作、操作ミスによって誘発される
  • 完全性向上の手段
    • アプリケーション監査、データのバックアップ、フールプルーフの導入など
• 機密性( Security :セキュリティ)
  • 機密性が高く、不正アクセスされにくいこと
  • 情報の漏洩、紛失、不正使用などを防止する能力
  • クラッカーの攻撃やテロリズム、自然災害などにシステムがどの程度脅かされているか
• システムの信頼性評価項目であるRASISのうち、Integrity(完全性)を高める方法
  • 排他制御を行うことによって、複数の利用者が同時にデータベースの更新処理を行う場合でも、データの整合性を保証する

割込み処理

• 実行中の処理を一時的に中断して、緊急度の高い別の処理を実行すること
• OSの中核部分であるカーネル(制御プログラム)は、デバイスドライバなどからの割込み通知を検出し、割込みの種類に応じた処理を行う
• 割込みの種類に応じた処理を行うプログラムは、割込みルーチンや割込みハンドラと呼ばれる
• あるプロセスの実行中に割込みが発生すると、カーネルは実行中のプロセスをいったん中断し、割込みルーチンに制御を移し、割込みルーチンが終了すると、原則的には割り込まれたプロセスに制御を戻す
• 割込みには、その発生要因によって、外部割込みと内部割込みの二つに大別することができる
• 外部割込み
  • プロセッサ以外のハードウェア(入出力装置やメモリのECC、ハードウェアタイマなど)によって生じる割込み
  • 分類
    • 入出力割込み
      • 入出力動作の完了、入出力装置の状態変化など
      • 入出力動作が終了したので、DMAコントローラからプロセッサへの通知が発生した
    • タイマ割込み
      • タイマ(計時機構)に設定された所定の時間が経過
    • 外部信号割込み
      • コンソールからの入力、他の処理装置からの連絡など
    • 異常割込み(機械チェック割込み)
      • 電源異常、処理装置/主記憶装置の障害など
• 内部割込み
  • プロセッサ内部の要因によって生じる割込み
  • 演算例外はプログラム割込みと呼ばれることもある
  • 制御プログラムに対するシステムコールをSVC(Super Visor Call)と呼ぶことから、ユーザプログラムが制御プログラムのサービスを利用するためにシステムコールを行うことSVC割込みという場合もある
  • SVC(Super Visor Call)割込みが発生する要因 ユーザプログラムがカーネルの機能を呼び出した
  • 分類
    • 演算例外
      • オーバフロー/アンダフローの発生、0による除算
      • ゼロで除算を実行したことによる割込み
      • 数値演算命令を実行したときに、序数が小さ過ぎたので、演算オーバフローが発生した
    • 不正な命令コードの実行
      • 存在しない命令や形式が一致しない命令を実行
    • モード違反
      • 特権モードの命令をユーザモードで実行
      • システム管理命令を一般ユーザモードで実行しようとしたので、特権命令違反が発生した
    • ページフォールト
      • 仮想記憶において存在しないページを指定
      • アクセスしようとしたページが主記憶に存在しないので、ページフォルトが発生した
    • 割出し
      • SVC命令の実行、トラップ処理など

メモリインタリーブ(memory interleaving)

• コンピュータの高速化技術の一つ
• 主記憶を幾つかの区画に分割し、連続したメモリへのアクセスを高速化する
• 主記憶を複数の独立して動作するグループ（バンク）やアクセス単位に分け、連続したメモリ領域を割り当て、この複数の領域へ並列にアクセスするすることで高速化する方式
• 主記憶を複数の独立したグループに分けて、各グループに交互にアクセスすることによって、主記憶へのアクセスの高速化を図る
• 複数のバンクに割り振った連続したアドレスにアクセスしたとき、アクセス時間を短くする
• 主記憶装置を、同時に並行して読み書き可能な複数の領域に分ける方式
• 主記憶を複数のバンクに分けて、CPUからのアクセス要求を並列的に処理できるようにする
• CPUから主記憶へのアクセスを高速化するために、主記憶内部を複数のバンクに分割し、各バンクを並列にアクセスする
• 主記憶の連続したアドレスを複数のブロックに分けて、並列的にアクセスすることでアクセスを高速化する
• メモリインタリーブを使用するとアクセス速度の遅いメモリを高速に使用できるようになるが、メモリの制御が複雑になるという問題もある

マルチプログラミング技術

• ソフトウェアの高速化のための技術
• マルチプログラミングの実現のためには、複数のプログラムに対してそれぞれ主記憶領域を割り当てる必要がある
• 割当てには、主記憶領域をあらかじめいくつかの区画(パーティション)に区切っておく固定区画方式と、ロードするプログラムの大きさに合わせて、そのつど適切な区画を作成・確保する可変区画方式とがある
• 可変区画方式では、固定区画方式のような内部フラグメンテーションは生じないが、複数プログラムのロード・実行を繰り返していると、主記憶上に細かい未使用領域が断片的に散在し、利用効率が低下する外部フラグメンテーションが発生する
• 外部フラグメンテーションが発生した場合、各プログラムの区画を配置し直すことで、未使用領域を集め、大きな空き領域を確保することができる、この作業をメモリコンパクションまたはガーベジコレクションと呼ぶ
• マルチプログラミングにおけるプロセスの切り替え手順を示した図

システム監査

システム監査の意義と目的

• システム監査は、監査対象から独立した立場で行う情報システムの監査であり、原則として情報システムが”システム管理基準”に準拠しているかどうかを確かめるためのもので、システムの企画・開発・運用・保守に責任を負うものではない
• 組織体がシステム監査を実施する目的
  • 情報システムにまつわるリスクに対するコントロールの整備・運用状況を評価し、改善につなげることによって、ITガバナンスの実現に寄与する
• 次の4項目が適切にコントロールされていることを総合的に点検・評価する
  • 情報システムが、組織体の経営方針および戦略目標の実現に貢献している
  • 情報システムが、組織体の目的を実現するよう安全、有効かつ効率的に機能している
  • 情報システムが、内部又は外部に報告する情報の信頼性が保たれるように機能している
  • 情報システムが、関連法令、契約又は内部規定等に準拠している

システム監査の対象業務

• システム監査の対象部門、対象業務は、事前調査によってリスクの高い部門や業務を見極めて選ぶ
• リスクアセスメントに基づく監査対象の選定
  • 問題発生の可能性とその影響の大きなシステムを対象とする
• システム監査の対象
  • 統制
    • 外部統制
      • 法律、条例などによる外部からのコントロール
    • 内部統制
      • 組織体が自発的に構築した仕組みによるコントロール
  • 情報資源
    • 内部統制
      • 情報資産の信頼性、安全性、効率性を確保、向上させるために設定された制度、組織、規準、手続きを総称するもの
    • 全般統制
      • 情報システムの全体にわたるコントロール
    • 業務処理統制
      • 個々の業務システムに特有なコントロール

システムの可監査性

• 処理の正当性や内部統制を効果的に監査できるように情報システムが設計・運用されていること
• コントロールの有効性を監査できるように、情報システムが設計・運用されていること

システム監査人の要件・役割・権限

• 監査対象から独立的かつ客観的立場のシステム監査の専門家として情報システムを総合的に点検及び評価し、組織体の長に助言及び勧告するとともにフォローアップする
• 監査対象から独立かつ専門的な立場から情報システムのコントロールの整備、運用を検証又は評価し、保証又は助言を行う
• 情報システムが企業活動に対して健全に機能しているかどうかを監査することによって、情報システム部門にアドバイスを与える
• システム監査人は、システム管理者に対して監査の実施に協力するよう要請できる
• システム監査人の独立性
  • 外観上の独立性：組織面で独立している
  • 精神上の独立性：監査意見が特定の人や組織の意向に左右されない
  • システム監査人の独立性が保たれている状況
    • 監査法人からシステム監査人を採用して内部監査人に位置づけ、社内の業務システム開発についての監査を行わせる
  • 情報システムの運用状況を監査する場合、監査人として適切な立場の者
    • 監査対象システムに関わっていないもの
  • 経営者が社内のシステム監査人の外観上の独立性を担保するために講じる措置
    • システム監査人の所属部署を経営者の直轄とする
    • システム監査人の所属部署を内部監査部門とする
    • 組織的な独立の他、過去の自己の業務に対する監査とならないか、被監査部門の長が監査人の元上司でないか、なども考慮する
  • 情報システム部が開発し、経理部が運用している会計システムの運用状況を監査するシステム監査チームの体制
    • 独立性を担保するために、システム監査チームは情報システム部にも経理部にも所属しない者で組織しなければならない
  • JIS Q 20000-1の「”サービスマネジメントシステムの監査及びレビュー”の要求事項
    • 監査員は、自らの仕事を監査してはならない
  • 独立性の観点から問題となるもの
    • 監査チームメンバに任命された総務部のAさんが、他のメンバと一緒に、総務部の入退室管理の状況を監査する
  • 独立性の観点から問題とならない
    • 監査部に所属しているBさんが、個人情報を取り扱う業務を委託している外部企業の個人情報管理状況を監査する
    • 情報システム部の開発管理者から5年前に監査部に異動したCさんが、情報システム部が行っているインターネット管理の状況を監査する
    • 情報システム部の開発管理者から5年前に監査部に異動したCさんが、マーケティング部におけるインターネットの利用状況を監査する
    • 法務部に所属しているDさんが、監査部からの依頼によって、外部委託契約の妥当性の監査において、監査人に協力する
• 適格性
  • 公正不偏な態度
  • 正当な注意義務、守秘義務
  • 監査に関する知識や能力
• 監査人の選定にあたっての留意点
  • 開発部門や利用部門からは独立した立場にあり、自らの判断に責任を持って監査の実施と客観的な評価ができる人を選ぶ
• 公認会計士が任意の業務としてシステム監査を実施する場合がある
• システム監査人は監査報告書に記載した監査意見に対して責任を負う
• 監査において発見した問題に対するシステム監査人の責任
  • 発見した問題を監査依頼者に報告する

システム監査計画

• 監査目的の明確化
  • 経営との整合性確認
  • 業務上の問題点の考慮
  • 監査の継続性
  • 資源の制約
• 監査手順書(監査手続き書)
  • 監査計画の段階で作成されるものであり、監査手続きと実施記録の記載欄から構成される
  • 監査証拠を入手するために作成されるが、システム監査担当者の指導監督を行うための有効な手段にもなる
  • 本調査における具体的な監査の進め方を示す
  • 監査業務の進捗管理に用いることができる
• 基本計画書
  • 重点監査テーマを設定する
• 個別計画書の記載内容
  • 監査目的
  • 監査対象
  • 監査範囲
  • 監査目標
  • 監査手続
  • 監査時期及び監査日程
    • 個別計画書に記述される監査時期、監査日程には、本調査だけでなく、予備調査や監査結果の報告会、フォローアップも含める
  • 監査責任者及び業務分担
  • 被監査部門責任者及び被監査部門担当者
  • 他監査との連携及び調整
  • 報告時期
  • 監査コスト
• 監査リスクモデル
  • 監査人が、監査リスクを一定水準以下に抑えることを目標に監査計画を立てるリスクアプローチ
  • 固有リスクと統制リスクを評価し、その高低に応じて発見リスクの水準を決める
  • 監査リスク＝固有リスク × 統制リスク × 発見リスク
  • リスクアプローチに基づく監査
    • 固有リスクと統制リスクのレベルが高く、その結果許容できる発見リスクを低く抑えなければならない場合、監査手続きを決めるに当たって監査人が採用すべき対応：外部証拠の入手範囲の拡大

システム監査の実施

• 実施準備
  • 個別計画書の内容を確認する
  • 被監査部門に対する事前通知
• 予備調査
  • 予備調査で行う作業
    • 監査対象の実態把握
    • 『システム監査基準』の定める予備調査
      • 本調査に先立って、監査対象業務の実態を把握するために行う調査
    • アンケート調査を行い、監査対象に対する被監査部門の管理者及び担当者のリスクの認識についての情報を収集する
    • 不正アクセス防止に関する取組状況を監査する場合、予備調査において、システム設計書によって、アクセスコントロール機能の内容を把握する
    • 監査対象に対する被監査部門の管理者及び担当者のリスクの認識について、アンケート調査によって情報を収集する
    • 被監査部門から事前に入手した資料を閲覧し、監査対象の実態を明確に把握する
    • システム監査において実施される"試査"
      • 抽出した一定件数のトランザクションデータに監査手続きを適用し、データ全件の正当性について判断する
• 本調査
  • 本調査の作業手順は、現状の確認、監査証拠の入手、証拠能力の評価の順に行う
  • 質問書
    • 監査の質及び効率を確保するために、標準の質問書を一部修正して利用するとよい
  • ヒアリング
    • ヒアリングの結果、問題と思われる事項を発見した場合は、その裏づけとなる記録の入手や現場確認を行う
    • ヒアリングに関するシステム監査人の行為
      • ヒアリングで被監査部門から聞いた話を裏付けるための文書や記録を入手するよう務める
• 評価・結論
  • 本調査の結果に基づいて評価・結論を検討する
  • 監査チェックリストの内容を検討して、問題として指摘する事項、評価できる項目に区分けして結論付ける
  • 評価は監査証拠に基づいて公平な判断基準に則って行う
  • 監査依頼者が監査報告に基づく改善指示を行えるように、システム監査人は監査結果を監査依頼者に報告する
  • システム監査チームが監査結果の評価を行ったとき、一部の項目について、調査不足から監査人の意見が分かれた場合の監査チームの対応
    • 意見の統一を図るために追加の監査手続を実施する
  • 内部監査として実施したシステム監査で、問題点を検出後、改善勧告を行うまでの間に監査人が考慮すべき事項
    • 監査人からの一方的な改善策の提案は実行不可能なものとなるおそれがあるので、改善勧告の前に、改善策について被監査部門との間で協議する場をもつ
  • 指摘事項
    • 監査人が判断基準に照らし合わせて問題と認めた事項のすべてを列挙する
    • 評価できる事項は指摘事項に含まれない
    • 調査結果に事実誤認がないことを監査対象部門に確認したうえで、監査人が指摘事項とする必要があると判断した事項を記載する
  • 改善勧告
    • 指摘事項の中から特に重要な事項を選択して改善を求める事項
    • 緊急改善勧告
      • そのまま放置できない重要な問題で、緊急に改善を必要とするもので、おおむね半年以内で実行するような事項
    • 通常改善勧告
      • それほどの緊急度を要しないが、改善の必要性のあるもの
      • 被監査部門は計画的に作業を進めていく必要がある
• システム監査実施上のリスク
  • 監査手続が実態と合っておらず、監査目的を達成できない
  • システム監査技術者の能力不足で、必要な監査証拠を入手できない
  • 現場が非協力的で監査がスムーズにできない
  • 監査の期間と費用が予算を大幅に上回ってしまう

システム監査の報告

• 指摘事項の適格性
  • 監査目的への適合性
  • 指摘事項の優先順位
  • 監査証拠による裏付け
  • 被監査部門、関係部門との意見交換
  • 関連法規、ガイドラインなどへの準拠性
• システム監査結果の数値による評価
  • 監査項目ごとに評価基準を設け、その乖離度を数値化し、総合評価は加重平均で行う
• システム監査報告書
  • システム監査報告書に記載された改善勧告に対して、被監査部門から提出された改善計画を経営者がITガバナンスの観点から評価する際の方針
    • 経営資源の状況を踏まえて改善を実施する
  • 監査の結果を権限者に報告する文書であり、システム監査人が問題ありと判断した事項は、指摘事項として全て記載する
  • システム監査人が、監査報告書の原案について被監査部門と意見交換を行う目的
    • 監査報告書に記載する指摘事項及び改善勧告について、事実誤認がないことを確認するため
  • システム監査人が監査報告書に記載する改善勧告に関する説明
    • 調査結果に事実誤認がないことを被監査部門に確認した上で、監査人が改善の必要があると判断した事項を記載する
  • システム監査報告書に記載された改善勧告に対する監査人の取組み
    • 改善勧告に対する改善実施状況を確認する
    • 発見事項と意見を明確に区分する
  • システム監査人が監査報告書に記載する事項のうち、監査人の業務範囲を逸脱するもの
    • 改善の命令
  • 監査意見
    • 保証意見：コントロールが有効に機能していることを保証する意見表明
      • 例
        • 販売管理システムに係る信頼性のコントロールは、システム管理基準に照らして、指摘事項に挙げた不備を除いて有効に機能している
    • 助言意見：欠陥の指摘と改善提言を行う意見表明
      • 例
        • 販売管理システムに係る安全性のコントロールに重大な不備があり、改善提案のように改善すべきである
        • 販売管理システムに係る効率性のコントロールは、業務処理に重大な影響を与える可能性があり、緊急の改善が必要である
        • 販売管理システムに係る信頼性のコントロールについて、被監査部門と合意した手続きによって調査を行った結果を、指摘事項として挙げた
• 責任の所在
  • システム監査人が負う責任
    • 監査報告書に記載した監査意見
  • システム監査の依頼者が負う責任
    • 監査結果の外部への開示
    • 監査報告会で指摘した問題点の改善
• フォローアップ活動
  • フォローアップ方法
    • 改善計画及び改善報告書の提出
    • 次回監査での確認
    • フォローアップ監査の実施
  • 被監査部門の改善活動状況において、計画通りに行われているかどうかを定期的に確認する
  • 業務改善そのものは被監査側が実施する
  • 改善提案に対する監査対象部門の改善状況をモニタリングする
  • システム監査報告書に記載された改善勧告への取組みに対する監査人のフォローアップ
    • 改善勧告に対する被監査部門の改善実施状況を確認する
  • システム監査の改善指導(フォローアップ)において、被監査部門による改善が計画よりも遅れていることが判明したとき、システム監査人が採るべき行動
    • 遅れを取り戻すための方策について、被監査部門の責任者に助言する
  • システム監査報告書に記載された改善勧告に対して、被監査部門から提出された改善計画を経営者がITガバナンスの観点から評価する際の方針
    • 経営資源の状況を踏まえて改善を実施する
  • システム監査のフォローアップにおいて、監査対象部門による改善が計画よりも遅れていることが判明した際に、システム監査人が採るべき行動
    • 遅れの原因を確かめるために、監査対象部門に対策の内容や実施状況を確認する

システム監査の品質評価

• 計画の品質管理
  • 監査手続書のレビュー
    • 個別計画に準拠しているか
    • 監査手続は効果的かつ効率的か
• 実施内容の品質管理
  • 監査調書のレビュー
    • 個別計画書及び監査手続書に準拠しているか
    • 監査調書として的確か
    • 意見表明過程は十分な根拠に基づいて行われているか
    • 監査調書に記載された事実は監査証拠として必要十分か
    • 監査担当者間で意見の整合性はとられているか
    • 総合評価は監査目的に適合しているか
    • 改善勧告は妥当な内容になっているか

システム監査基準

• システム監査基準の役割
  • 監査人の行動規範として、システム監査業務の品質を確保し、有効かつ効率的に監査を実施するために利用する基準
  • システム監査業務の品質を確保し、有効かつ効率的に監査を実施することを目的としたシステム監査人の行動規範
• システム監査の目的
  • 組織体の情報システムにまつわるリスクに対するコントロールがリスクアセスメントに基づいて適切に整備・運用されているかを評価する
  • 独立かつ専門的な立場のシステム監査人が検証又は評価することによって、保証を与えあるいは助言を行い、もってITガバナンスの実現に寄与する
  • 情報システムにまつわるリスクに対するコントロールの整備・運用状況を評価し、改善につなげることによって、ITガバナンスの実現に寄与する
  • 情報セキュリティに係るリスクのマネジメントが効率的に実施されるよう、リスクマネジメントに基づくコントロールの整備・運用の状況を評価すること
  • リスクに対するコントロールをシステム監査人が評価し、保証又は助言を行い、ITガバナンスの実現に寄与すること
• 一般基準
  • 目的・権限と責任
    • 役割と権限
      • システム監査人は、システム管理者に対して監査の実施に協力するよう要請できる
  • 独立性、客観性と職業倫理
    • システム監査人の精神上の独立性
      • 偏向を排し、常に公平性かつ客観的に監査判断を行う
    • 職業倫理
      • システム監査は、企業の内部監査として実施されるものであり、企業の利益保護の立場から監査判断を行う
    • 監査責任者及びメンバの選出
      • あるメンバを、当該メンバが過去に在籍していた部門に対する監査に従事させる場合、一定の期間を置く
  • 専門能力
  • 業務上の義務
    • 監査目的に応じた監査報告書を作成し、遅滞なく監査依頼者に提出する
  • 品質管理
    • システム監査結果の適正性を確保すること
    • 監査に対する監査依頼者のニーズを満たしているかどうかを含め、監査品質を確保するための体制を整備する
• 実施基準
  • 監査計画の立案・策定
    • 経営トップにインタビューを行い、現在抱えている問題についての認識を確認することによって、システムに監査に対するニーズを把握する
    • 個別監査計画を策定するために、監査スケジュールについて監査対象部門と調整を図る
    • リスクアプローチ
      • 情報システムリスクは常に一定ではないことから、情報システムリスクの特性の変化及び変化がもたらす影響に留意する
    • 監査対象として考慮する項目
      • マネジメント
        • IT投資管理や情報セキュリティ対策がPDCAサイクルに基づいて、組織全体として適切に管理されているか
      • ガバナンス
        • IT戦略と経営戦略の整合性がとらわれているか、新技術やイノベーションの経営戦略への組込みが行われているか
      • コントロール
        • 規定に従った承認手続きが実施されているか、異常なアクセスを検出した際に適時な対処及び報告が行われているか
        • 組織の業務プロセスなどにおいて、リスクに応じた統制が組み込まれているか
  • 監査の手順
    • 予備調査
      • 監査対象部門の事務手続きやマニュアルなどを通じて、業務内容、業務分掌の体制などを把握するするために行う調査
      • 監査対象に対する被監査部門の管理者及び担当者のリスクの認識について、アンケート調査によって情報を収集する
    • 本調査
      • 被監査部門の担当者に対して、監査手続書に従ってヒアリングを行い、監査対象の実態を詳細に調査する
      • 現状の確認
      • 監査証拠の入手
      • 証拠能力の評価
    • 評価・結論
  • 監査の実施
    • システム監査の実施手順
      • 監査目的の設定
      • 監査対象業務の把握
      • 監査手続書の作成
      • 証拠の収集
      • コントロールの評価・結論
  • 監査業務の体制
    • 監査依頼者が監査報告に基づく改善指示を行えるように、システム監査人は監査結果を監査依頼者に報告する
    • システム監査規程の最終的な承認者
      • 経営者
    • 社内におけるシステム監査実施部門の位置づけ
    • システム監査組織の形態
      • 独立したシステム監査部門型
      • 委員会型
      • プロジェクトチーム型
      • 外部機関へのアウトソーシング型
  • 他の専門職の利用
  • 情報セキュリティ監査
• 報告基準
  • 監査報告書の提出と開示
  • 監査報告の根拠
  • 監査報告書の記載事項
  • 監査報告についての責任
  • 監査報告に基づく改善指導
    • 改善勧告のフォローアップ
      • システム監査人は、監査対象部門が提出した改善実施状況報告書の確認に加え、改善内容の追加的な検証が必要かどうかを検討する
      • システム監査人が、監査報告書に記載した改善提案の実施状況に関する情報を収集し、改善状況をモニタリングすること
  • システム監査報告書
    • 監査対象に関する手順書や実施記録、及び被監査部門から入手した監査証拠に基づいて、指摘事項をまとめる
    • 被監査部門の管理者の説明を受けながら、被監査部門が業務を行っている現場を実際に見て、改善提案の実現可能性を確かめる
    • 経済産業省"情報セキュリティ監査基準 実施基準ガイドライン(Ver1.0)"における、情報セキュリティ対策の適切性に対して一定の保証を付与することを目的とする監査(保証型の監査)と情報セキュリティ対策の改善に役立つ助言を行うことを目的とする監査(助言型の監査)の実施に関する記述
      • 不特定多数の利害関係者の情報を取り扱う情報システムに対しては、保証型の監査を定期的に実施し、その結果を開示することが有用である
    • システム監査基準(平成30年)の"監査の結論の形成"において規定されているシステム監査人の行為
      • 保証を目的とした監査であれ、助言を目的とした監査であれ、監査の結論を表明するための合理的な根拠を得るまで監査手続きを実施する
    • 助言型報告書
      • システム監査人と被監査部門の責任区分の存在は当然であるが、保証型報告書とは異なり、責任区分にあえて言及する必要はない
    • 保証型報告書
      • コントロールの改善を目的として問題点を検出・提示するためにシステム監査を実施した旨を記載する必要がある
      • 監査意見が監査証拠を評価した結果得られた根拠に基づく保証である旨を記載する必要がある
      • システム監査人は自ら実施した方法と結論だけに責任を負う旨を記載必要がある
      • 情報セキュリティ監査基準(Ver1.0)に基づく保証型監査の意見表目において、監査人が必要と認めた監査手続が制約され、保証意見の合理的な根拠を得ることができなかった場合の対応
        • 保証意見を表明しない

システム監査技法

• ヒアリング
  • ヒアリングで被監査部門から得た情報を裏付けるための文書や記録を入手するよう努める
• チェックリスト法
  • 監査人がチェック項目をリストアップして使用する
• ドキュメントレビュー法
  • 文書の内容を確認する
  • 監査対象の状況に関する監査証拠を入手するために、システム監査人が、関連する資料及び文書類を入手し、内容を点検する
• 突合法、照合法
• 現地調査法
  • 被監査部門に出掛けて直接その実態を観察する
• インタビュー法
  • 被監査部門の管理者や担当者に直接質問を行って実態を確認する
  • インタビューで監査対象部門から得た情報を裏付けるための文書や記録を入手するよう努める
  • 監査対象の実体を確かめるために、システム監査人が、直接、関係者に口頭で問い合わせ、回答を入手する
• 統計的サンプリング法
  • サンプルの抽出に無作為抽出法を用い、サンプルの監査結果に基づく母集団に関する結論を出すにあたって、確率論の考え方を用いる
  • コントロールが有効であると判断するために必要なサンプル件数を事前に決めることができる
  • 許容誤謬率
    • サンプルの件数を決めるときに用いるものであって、監査人が受け入れることのできる所定の内部統制からの逸脱率である
  • 許容逸脱率
    • 受け入れることができる所定の内部統制からの逸脱率であり、監査人がサンプルの件数を決めるときに用いられる指標
  • サンプリングリスク
    • サンプルが母集団の特性を正確に反映しないために、監査人が母集団について誤った結論を行うリスク
  • 母集団
    • 監査の対象となる集団の全体のこと
• アンケート
  • 監査対象部門から対象者を選び、監査テーマについて監査人が作成した質問に答えてもらう
  • 予備調査で状況確認などに用いる
• ウォークスルー法
  • データの生成から入力、処理、出力、活用までのプロセス、及び組み込まれているコントロールを、システム監査人が書面上で又は実際に追跡する技法

コンピュータ支援監査技法(CAAT)

• コンピュータを利用して行うシステム監査技法

  	主な機能	主な機能	主な機能	主な機能	主な機能	主な機能
  技法	システムのテスト	稼働中オンラインシステムのテスト	プログラムロジックの分析	プログラムの検証	データの抽出	稼働中オンラインシステムからのデータ抽出
  テストデータ法	○
  汎用監査ソフトウェア法					○
  組込み監査モジュール法					○	○
  ITF法	○	○
  並行シミュレーション法	○		○
  スナップショット法			○
  トレーシング法			○
  コード比較法				○

• テストデータ法
  • テストデータを作成し、あらかじめ計算しておいたとおりの結果が出力されるかどうかを検証する
  • システムが設計通り動いているかどうかを検証する
  • テスト対象プログラムのロジックが本番で稼働しているものと同一であるかを確認
  • あらかじめシステム監査人が準備したテスト用データを監査対象プログラムで処理し、期待した結果が出力されるかどうか確かめる
• 汎用監査ソフトウェア法(監査プログラム法)
  • コンピュータシステムに記憶されている監査対象データを検索・抽出し、比較・加工・集計などの演算を行って編集し、結果を報告書として出力することができるように開発されたソフトウェアを利用する監査技法
• 組込み監査モジュール法
  • 本番業務処理システムの中に監査モニタルーチンを組み込み、監査対象となる適用業務システムを通過する取引について監視する
  • 監査機能を持ったモジュールを監査対象プログラムに組み込んで実環境下で実行し、抽出条件に合った例外データ、異常データなどを収集し、監査対象プログラム処理の正確性を検証する
• ITF法(Integrated Test Facility)
  • 監査対象ファイルにシステム監査人用の口座を設け、実稼動中にテストデータを入力し、その結果をあらかじめ用意した正しい結果と照合して、監査対象プログラムの処理の正確性を検証する方法
• 並行シミュレーション法
  • システム監査人が用意した検証用プログラムと監査対象プログラムに同一のデータ(本番データ)を入力し、両者の実行結果を比較することによって、監査対象プログラムの処理の正確性を検証する
• スナップショット法
  • 特定のデータが通過したり、一定の条件が成立したりした時点で、メモリの内容を出力することによって、本番環境下での処理の途中結果の妥当性を検証するシステム監査技法
  • プログラムの検証したい部分を通過した時の状態を出力し、それらのデータを基に監査対象プログラムの処理の正確性を検証する
• トレーシング法
  • プログラム処理経路を分析することによって、プログラム論理のフローの正確性・妥当性を検証する技法
• コード比較法
  • 本番稼働後のプログラムの変更管理が正当に行われているかどうか調べるために、変更前と変更後のコードを比較し、その差異が設計・承認されたとおりのものとなっていることを確認する

監査手続

• 監査項目について、十分かつ適切な証拠を入手するための手順
• コントロールの点検、評価を行うために実施する
  • 準拠性テスト
  • 実証性テスト
• 分類
  • 精査：全件に対して監査手続を適用する
  • 試査：一部に対して監査手続を適用する

監査証拠

• 監査意見を立証するために必要な事実
• 監査人が監査手続きを実施して収集した資料を監査人の判断に基づいて評価した結果
• 必要に応じて被監査部門から入手した証拠資料を添付する
• 被監査部門以外の第三者から入手した文書は、被監査部門から入手した同種の文書よりも監査証拠としての証明力が強い
• 監査人が収集又は作成する資料であり、監査報告書に記載する監査意見や指摘事項は、その資料によって裏付けられていなければならない
• 現場調査では、監査人が見た実体と被監査部門からの説明を総合的に判断して、監査証拠とする
• システム監査基準(平成30年)における"十分かつ適切な監査証拠"を説明したもの
  • 証拠としての量的十分性を備え、システム管理基準に適合し、かつ情報システムから出力された証拠
• 種類
  • 物理的証拠：システム監査人自らが検証したもの
  • 文書的証拠：システム監査人が内容を検証した文書的、電磁的記録物
  • 口頭的証拠：システム監査人が証拠になると判断した証言、説明
  • 状況的証拠：システム監査人自らが観察した状況
• 証拠能力(１：強→４：弱)
  • システム監査人が取引記録と実際の在庫とを照合した結果
  • テストデータ法によって得られた処理結果
  • システム監査人がシステムテストに関するドキュメントをレビューした結果
  • 運用担当者が記録したシステム運用に関するメモ
• 監査証拠となるもの
  • システム監査チームが被監査部門から入手したシステム運用記録
• 監査証拠とならないもの
  • システム監査チームが監査意見を取りまとめるためのミーティングの議事録
  • システム監査チームが監査報告書に記載した指摘事項
  • システム監査チームが作成した個別監査計画書
• 監査証拠の入手
  • 適切ではないもの
    • アジャイル手法を用いたシステム開発プロジェクトにおいては、管理用ドキュメントとしての体制が整っているものだけが監査証拠として利用できる
  • 適切なもの
    • 外部委託業務実施拠点に対する現地調査が必要と考えたとき、委託先から入手した第三者の保証報告書に依拠できると判断すれば、現地調査を省略できる
    • 十分かつ適切な監査証拠を入手するための本調査の前に、監査対象の実態を把握するための予備調査を実施する
    • 一つの監査目的に対して、通常は、複数の監査手続きを組み合わせて監査を実施する

監査調書

• 監査調書の役割として、監査実施内容の客観性を確保し、監査の結論を支える合理的な根拠とすることなどが挙げられる
• システム監査人が行った監査手続きの実施記録であり、監査意見表明の根拠となるべき監査証拠、その他関連資料などをまとめたもの
• 必要に応じて被監査部門から入手した証拠資料を添付して保管する
• 監査業務の全過程において、監査人が収集及び作成した資料
• 監査人が行った監査手続の実施記録であり、監査意見の根拠となる
• システム監査の実施内容を記録した資料
  • システム監査人が監査の実施内容を記録した資料
  • システム監査人が被監査部門から入手した文書
• 作成の留意点
  • 真実性(内容が真実である)
  • 立証性(監査意見を立証)
  • 完全性(監査プロセス全体を文書化)
  • 秩序性(記載事項が体系的に整理されている)
  • 明解性(記載内容が完結で明瞭である)
  • 経済性(費用対効果を考慮した監査である)
  • 現時性(実施時点で逐次作成)
• 監査調書に対する不適切な扱い
  • 監査調書には、監査対象部門以外においても役立つ情報があるので、全て企業内で公開すべきである
  • 監査調書は、通常、電子媒体で保管されるが、機密保持を徹底するためバックアップは作成すべきではない
  • 監査調書は監査の過程で入手した客観的な事実の記録なので、監査担当者の所見は記述しない

監査証跡

• 運用環境を含めた監査対象システムの入力から出力に至る過程を追跡できる一連の仕組みと記録
• 監査対象システムの入力から出力に至る過程を追跡できる一連の仕組みと記録
• 処理過程をすべて記録･保存しておくことは経済性・効率性を損なう可能性があるので、必要十分な監査証跡を決定し、確保することが大切である
• 監査証跡の例
  • イントラネットシステムの運用業務の監査証跡
    • Webサーバへのアクセスログ
  • 情報システムの安全性のコントロールに関係する監査証跡
    • アクセスログ
  • システム運用業務(オペレーション)に関するシステム監査証跡
    • 出力情報のエラー状況に関する記録

助言型監査

• 監査対象の情報システムに関するリスクに対するコントロールの改善を目的として、コントロールの問題点を検出し、改善提言を監査意見として表明する形態の監査

保証型監査

• 監査手続きを実施した限りにおいて、監査対象の情報セキュリティに関するマネジメントやコントロールが適切であることを保証する監査
• システム監査を保証型で行う目的
  • 外部利害関係者からの信頼獲得

内部監査で求められる事項

• 監査の対象となるプロセスや領域の状況、重要性、前回までの監査結果などを考慮し、監査プログラムを策定しなければならない
• 監査の基準、範囲、頻度、方法を定義しなければならない
• 監査員の選定と監査の実施においては、監査プロセスの客観性と公平性を確実にしなければならない
• 監査の計画や実施、及び結果報告と記録維持に関する責任と要求事項を、文書化した手順の中で定義しなければならない
• 監査対象の領域に責任を持つ管理者は、発見された不適合やその原因が遅滞なく除去されるようにしなければならない
• 監査のフォローアップには、採った処置の検証及び検証結果の報告を含めなければならない
• 内部監査として実施したシステム監査で、問題点を検出後、改善勧告を行うまでの間に監査人が考慮すべき事項
  • 監査人からの一方的な改善提案は実行不可能なものとなるおそれがあるので、改善勧告の前に、改善策について被監査部門との間で協議する場をもつ
• 内部監査とシステム監査の関係
  • ソフトウェアの品質確保の観点から行うシステム監査は、ISO9001:2000の内部監査に相当する場合がある

システム監査のチェックポイント

• システム設計の段階において、ユーザ要件が充足されないリスクを低減するコントロールを監査するときのチェックポイント
  • 利用部門が参画して、システム設計書のレビューを行なっていること
• ドキュメント管理において、稼働しているシステムの仕様とドキュメントの内容が一致しないリスクを低減するコントロールのチェックポイント
  • プログラム変更に伴い、ドキュメントを遅滞なく更新すること
• ソースコードのバージョン管理システムが導入された場合に、システム監査において、ソースコードの機密性のチェックポイント
  • バージョン管理システムのアクセスコントロールの設定が適切であること
• 経済産業省の”営業秘密管理指針”に基づく営業秘密データの管理状況に突いて監査を行うとき、秘密管理性のチェックポイント
  • 当該データの記録媒体に秘密を意味する表示をしていること
• システムテストの監査におけるチェックポイント
  • 例外ケースや異常ケースを想定したテストが行われていること
• システムの本番移行に支障を来すリスクに対するコントロールを監査するチェックポイント
  • ユーザ部門を含めた各部門の役割と責任を明確にした移行計画が作成されているか
• ペネトレーションテストが最も適合するチェックポイント
  • ネットワークへのアクセスコントロールが有効に機能しているか
• セキュリティ対策
  • オフィスへの入退に、不正防止及び機密保護の物理的な対策が講じられているか
• プルーフリスト(proof list)
  • データ入力が漏れなく、重複なく正確に行われているか
• トラフィックログと分析結果
  • ネットワークの負荷状況の推移が記録、分析されているか
• ソフトウェアの資産管理に対する監査のチェックポイント
  • ソフトウェアのライセンス証書などのエビデンスが保管されているか
• ソフトウェアのパッチの適用において、システムに不具合が発生するリスクを低減するコントロールを監査する際のチェックポイント
  • 本稼働前にシステムの動作確認を十分に実施していること- スプレッドシートの処理ロジックの正確性に関わるコントロールを監査する際のチェックポイント
  • スプレッドシートのプログラムの内容が文書化され検証されていること
• スプレッドシートの処理内容の正確さに関わるコントロールを監査する際のチェックポイント
  • スプレッドシートのプログラムの内容が文書化され検証されていること
• システムの本番移行に支障を来すリスクに対するコントロールを監査するチェックポイント
  • 利用部門を含めた各部門の役割と責任を明確にした移行計画が作成されている
• システムに関わるドキュメントが漏えい、改ざん、不正使用されるリスクに対するコントロールを監査する際のチェックポイント
  • ドキュメントの機密性を確保するための対策を講じていること
• 在庫管理システムを対象とするシステム監査において、当該システムに記録された在庫データの網羅性のチェックポイント
  • 入庫及び出庫記録に対して、自動的に連番を付与していること
• クラウドサービスの導入検討プロセスに対するシステム監査において、クラウドサービス上に保存されている情報の消失の予防に関するチェックポイント
  • クラウドサービスを提供する事業者に信頼が置け、かつ、事業やサービスが継続して提供されるかどうかが検討されているか
  • クラウドサービスを提供する事業者が信頼できるか、事業者の事業継続性に懸念がないか、及びサービスが継続して提供されるかどうかが検討されているか
• 経済産業省の”営業秘密管理指針”に基づく営業秘密データの管理状況について監査を行うときのチェックポイント
  • 秘密管理性のチェックポイント
    • 当該データの記録媒体に秘密を意味する表示をしていること
  • 有用性のチェックポイント
    • 当該データが経営効率の改善に役立っているかどうかを分析していること
  • 非公知性のチェックポイント
    • 当該データの内容が刊行物に掲載されていないかを定期的に確認していること
  • 有用性のチェックポイント
    • 当該データの内容が公序良俗に反していないかを確認していること
• システムテストの監査におけるチェックポイント
  • 適切なもの
    • テストケースが網羅的に想定されていること
  • 不適切なもの
    • テスト計画は事前に利用者側の責任者だけで承認されていること
    • テストは実際に業務が行われている環境で実施されていること
    • テストは利用者側の担当者だけで行われていること
• マスタファイル管理に関するシステム監査項目
  • 可用性に該当するもの
    • マスタファイルが置かれているサーバを二重化し、耐障害性の向上を図っていること
  • 使い勝手
    • マスタファイルのデータを複数件まとめて検索・加工するための機能が、システムに盛り込まれていること
  • 機密
    • マスタファイルのメンテナンスは、特定アカウントを付与された者だけに許されていること
  • 完全性
    • マスタファイルへのデータ入力チェック機能が、システムに盛り込まれていること
• 被監査企業がSaaSをサービス利用契約して業務を実施している場合、被監査企業のシステム監査人がSaaSの利用環境からSaaSへのアクセスコントロールを評価できる対象のID
  • アプリケーションの利用者ID

システム監査の事例

• 会計に関する監査
  • コストセンタであるシステム部門において、システムコスト配賦の妥当性を確かめるための監査手続き
    • システム部門のシステムコストを、ユーザ部門に合理的な方法で配賦しているかどうかを確かめる
  • 月末に売り上げ形状を行う販売情報システムにおいて、架空売り上げに対する監査上の判断
    • 月初に前月分の売り上げ取消し件数が多いので、その原因を確かめた上で不正が行われていないかどうかを判断することにした
  • 現金による回収以外の理由で売掛金が減少したとき、会計データベースを対象として原因を調査する適切な方法
    • 貸方が”売掛金”で、借方が”現金”以外の勘定科目となっているデータを抽出し、その取引について、内容及び理由を確かめる
  • 販売管理システムにおいて、起票された受注伝票が漏れなく、重複することなく入力されていることを確かめる監査手続
    • プルーフリストと受注伝票との照合が行われているか、プルーフリスト又は受注伝票上の照合印を確かめる
• セキュリティに関する監査
  • ISMS認証基準(JIS Q 27001:2006)の詳細管理策を基に設定した、ノートPCに対する物理的安全対策の妥当性を確認するため、オフィス内を視察し、不在者のノート型PCが施錠されたキャビネットに保管されていることを確認する
  • 情報セキュリティに関する従業員の責任について、”情報セキュリティ監査基準”に基づいて監査を行った
  • 情報システムのコントロールの評価を整備状況の評価と運用状況の評価に分けたときのユーザのシステムへのログインパスワード管理
    • 運用状況の評価
      • パスワードを管理しているファイルから抽出したサンプルについて、パスワードの設定状況を確認する
    • 整備状況の評価
      • システム仕様書の承認ルールを閲覧して、パスワード管理方針に基づいた設計が行われていることを確認する
      • システム部門の責任者への質問によって、パスワード管理に関する会社の方針を確認する
      • パスワード管理マニュアルを閲覧して、パスワード設定ルールを確認する
• 情報システムに関する監査
  • システムの有効性の監査
    • システムが計画通りに効果をもたらしているかどうかを評価する
  • 情報システムの可用性監査において、システム障害報告書に基づき再発防止策の効果をレビューする手続
    • 前期及び当期の障害原因別の障害発生件数と停止時間の比較
• データ管理に関する監査
  • 適切なアクセスコントロールを行っているか確認する
  • マスタファイル管理に関するシステム監査項目のうち可用性に該当するもの
  • マスタファイルがおかれているサーバを二重化し、耐障害性の向上を図っていること
• アクセス制御に関する監査
  • データに関するアクセス制御の管理状況を確認する
  • アクセス権限を管理しているシステムの利用者IDリストから、退職による権限喪失者が削除されていることを検証する手続
  • 人事発令簿の退職者の全件について、利用者IDリストから削除されていることを確認する
  • 被監査企業がSaaSをサービス利用契約して業務を実施している場合、被監査企業のシステム監査人がSaaSの利用者環境からSaaSへのアクセスコントロールを評価できる対象のID
    • アプリケーションの利用者ID
• テストに関する監査
  • システムテスト(総合テスト)で使用するテストデータの作成に対する監査項目
    • テストチームが、業務活動の中でシステムが使用されるケースを想定してテストデータを作成しているか
  • "システム管理基準"でいう、システムテストの総合テストで使用するテストデータの作成に対する監査項目
    • テストチームが、業務活動の中でシステムが使用されるケースを想定してテストデータを作成しているか
  • 指摘事項となるもの
    • システムテスト(総合テスト)について、本番と同様のデータファイルを使用してテストを実施している
• ユーザ受け入れテストの監査
  • システム開発委託先(受託者)から委託元(委託者)に納品される成果物に対する受入れテストの適切性を確かめるシステム監査の要点
    • 受託者から納品された成果物に対して、委託者が受入れテストを実施していること
• 請負契約に関する監査
  • 外部委託した場合の品質管理の妥当性を確認するための監査項目
    • 委託元は開発工程の決められた時点で成果物のレビューを行い、問題点が委託先によって解決されていることを確認しているか
• 個人情報保護に関する監査
  • 営業部門では、情報システムから出力した顧客リストを、全社で定めたルールどおりに取り扱っていないとの指摘を受けたとき、指摘事項に基づく改善計画の策定責任者
    • 営業部門の責任者
  • 個人情報の取得に関して、"JIS Q 15001:2006"における個人情報取得時の要求事項への準拠性を監査する
• 外部委託管理に関する監査
  • 請負契約において、受託側要員が委託側の事務所に勤務している場合は、受託側のアクセス管理が妥当かどうかを委託側が監査できるように定める
  • 経営破綻などによってソフトウェア資産のメンテナンスが受けられなくなることを防ぐために確認すべき契約項目
    • ソフトウェアのソースコードなどを第三者へ預託するエスクロウ条項
  • システム開発を外部委託している部門が、委託先に対する進捗管理についてシステム監査を受ける場合、提出すべき資料
    • 委託先から定期的に受領している業務報告及びその検証結果を示している資料
  • 請負契約においては、委託側の事務所で作業を行っている受託側要員のシステムへのアクセスについて、アクセス管理が妥当かどうかを、委託側が監査できるように定める
  • 請負契約においては、受託側要員に対する委託者側責任者の指揮命令が行われていることを、受託側で監査する
  • 外部委託で開発した業務システムの品質管理の状況は、委託側で監査する
  • 外部委託に関するシステム監査において、経営破綻などによってソフトウェア資産のメンテナンスが受けられなくなることを防ぐために確認すべき契約項目
    • ソフトウェアのソースコードなどを第三者へ預託するエスクロウ条項
• データベースに関する監査
  • データベースの監査ログを取得する目的
    • 問題のあるデータ操作を事後に調査する
  • データベースのインテグリティ監査
    • データベース資源へのアクセスをモニタリングする機能が組み込まれているかどうかを確認する
    • データベースのデータに不具合が発生した場合の障害回復手段が組み込まれているかどうか
  • データベースに対する不正アクセスの防止・発見を目的としたアクセスコントロールについて"システム管理基準"への準拠性を確認する監査手続き
    • 利用者のデータベースに対するアクセス状況を確認するために、アクセス記録を出力し内容を調査する
  • データベースの直接修正に関して、監査人がシステム監査報告書で報告すべき指摘事項(ここで、直接修正とは、アプリケーションの機能を経由せずに、特権IDを使用してデータを追加、変更又は削除すること)
    • 指摘事項
      • 更新ログを加工して、アプリケーションの機能を経由した正常な処理によるログとして残していた
    • ならないもの
      • 事前のデータ変更申請の承認、及び事後のデータ変更結果の承認を行っていた
      • 直接修正の作業時以外は、使用する直接修正用の特権IDを無効にしていた
      • 利用部門からのデータ変更依頼票に基づいて、システム部門が直接修正を実施していた
• システム運用業務のオペレーション管理に関する監査で判明した状況
  • 指摘事項として監査報告書に記載すべきもの
    • オペレータが、日次の運用計画を決定し、自ら承認している
  • 記載しなくても良いもの
    • 運用責任者が、オペレータの作成したオペレーション記録を確認している
    • 運用責任者が、期間を定めてオペレーション記録を保管している
    • オペレータが、オペレーション中に起きた例外処理を記録している
• 開発プロジェクトにおいて、開発検討フェース、プログラムテストフェーズ、移行判定フェーズを対象とし、それぞれのフェーズ終了時に監査を実施する場合、各フェーズで実施することが適切な監査手続
  • 開発検討フェーズ
    • 開発目的や開発体制があらかじめ検討されたうえで開発が実施されたことを確認するために、開発計画書を閲覧する
    • システムの実現方法や代替案を検討したことを確認するために、フィージビリティスタディ報告書を閲覧する
  • プログラムテストフェーズ
    • テスト計画が策定されたうえでプログラムテストに着手されたことを確認するために、プログラムテスト計画書を閲覧する
  • 移行判定フェーズ
    • システムの品質が本番稼働にとって問題がないことの判断資料が作成されていることを確認するために、品質報告書を閲覧する
• A社では、自然災害などの際の事業継続を目的として、業務システムのデータベースのバックアップを取得している。その状況について、"情報セキュリティ監査基準(平成28年)"に従って実施した監査結果として判明した状況
  • 監査人が指摘事項として監査報告書に記載すべきもの
    • バックアップを取得した電子記録媒体を、業務システムが稼働しているサーバの近くで保管していた
  • しなくてもよいもの
    • バックアップ取得手順書を作成し、取得担当者を定めていた
    • バックアップを取得した電子記録媒体からデータベースを復旧する経験を、事前に定めたスケジュールに従って実施していた
    • バックアップを取得した電子記録媒体を、機密保持を含む契約を取り交わした外部の倉庫会社に委託管理していた
• システム利用者に対して付与されるアクセス権の管理状況の監査で判明した状況
  • 監査人がシステム監査報告書で報告すべき指摘事項
    • 退職・異動したシステム利用者に付与されていたアクセス権の削除・変更は、定期人事異動がある年度初めに全てまとめて行われていた
  • 指摘事項ではない
    • アクセス権を付与された利用者ID・パスワードに関して、システム利用者が遵守すべき事項が規定として定められ、システム利用者に周知されていた
    • 業務部門長によって、所属するシステム利用者に対するアクセス権の付与状況のレビューが定期的に行われていた
    • システム利用者に対するアクセス権の付与・変更・削除に関する管理手続きが、規定として定めらていた
• 事業継続計画(BCP)について監査を実施した結果
  • 適切な状況と判断されるもの
    • 従業員の緊急連絡先リストを作成し、最新版に更新している
  • 不適切
    • 重要書類は複製せずに1か所で集中保管している
    • 全ての業務について優先順位なしに同一水準のBCPを策定している
    • 平時にはBCPを従業員に非公開としている
• 販売管理システムにおいて、起票された受注伝票の入力が、もれなく、かつ、重複することなく実施されていることを確かめる監査手続き
  • 適切
    • 販売管理システムから出力したプルーフリストと受注伝票との照合が行われているか、プルーフリストと受注伝票上の照合印を確かめる
  • 不適切
    • 受注データから値引取引データなどの例外取引データを抽出し、承認の記録を確かめる
    • 受注伝票の入力時に論理チェック及びフォーマットチェックが行われているか、テストデータ法で確かめる
    • 並行シミュレーション法を用いて、受注伝票を処理するプログラムの論理の正当性を確かめる
• 提案依頼書(RFP)によるベンダ選定手続きに関するシステム監査で判明した状況
  • 指摘事項として監査報告書に記載すべきもの
    • RFP発効後、問い合わせをしてきたITベンダだけに対して追加資料を提供していた
  • 不要
    • RFPに、システム化要求事項のほか、あるべき業務モデルも添付していた
    • 提案を希望するITベンダだけを集めて、RFP説明会を実施していた
    • 予算額の範囲を、RFPに明示していた
• プライバシーマークを取得しているA社は、個人情報管理台帳の取扱いについて内部監査を行った。判明した状況
  • 監査人が指摘事項として監査報告書に記載すべきもの
    • 個人情報管理台帳の見直しは、新たな個人情報の取得があった場合にだけ行っている
  • 指摘事項ではないもの
    • 個人情報管理台帳に、概数でしかつかめない個人情報の保有件数は概数だけで記載している
    • 個人情報管理台帳に、ほかの項目に加えて、個人情報の保管場所、管理方法、保管期限を記載している
    • 個人情報管理台帳の機密性を守るための保護措置を講じている
• ソフトウェア開発プロセスにおけるセキュリティを確保するための取組について、JIS Q 27001:2014(情報セキュリティマネジメントシステム―要求事項)の付属書Aの管理策に照らして監査を行った
  • 判明した状況のうち、監査人が監査報告書に指摘事項として記載すべきもの
    • ソフトウェア開発におけるセキュリティ機能の試験は、開発期間が終了した後に実施している
  • 指摘事項とならないもの
    • ソフトウエア開発は、セキュリティ確保に配慮した開発環境において行っている
    • ソフトウエア開発を外部委託している場合、外部委託先による開発活動の監督・監視において、セキュリティ確保の観点を考慮している
    • パッケージソフトウエアを活用した買いは湯において、セキュリティ確保の観点から、パッケージソフトウェアの変更は必要な変更に限定している
• 外部保管のために専門業者に機密情報を含むバックアップ媒体を引き渡す際の安全性について、情報セキュリティ監査を実施した結果として判明した状況
  • 監査人が指摘事項として監査報告書に記載すべきもの
    • 委託元担当者が、バックアップ媒体をダンボール箱に入れ、それを専門業者に引き渡している
  • 記載しなくてもよいもの
    • 委託元責任者が、一定期間ごとに、専門業者における媒体保管状況を確認する契約を結んだ上で引き渡している
    • 委託元責任者が、専門業者との間で、機密保持条項を盛り込んだ業務委託契約を結んだ上で引き渡している
    • 委託元担当者が、専用の記録簿に、引渡しの都度、日付と内容を記入し、専門業者から受領印をもらっている
• 情報セキュリティに関する従業員の責任について、”情報セキュリティ管理基準”に基いて監査を行った。
  • 指摘事項
    • 雇用の終了をもって守秘義務が解消されることが、雇用契約に定められている
  • 指摘事項とならないもの
    • 定められた勤務時間以外においても守秘責任を負うことが、雇用契約に定められている
    • 定められた守秘責任を果たさなかった場合、相応の措置がとられることが、雇用契約に定められている
    • 定められた内容の守秘義務契約書に署名することが、雇用契約に定められている
• 新システムへの移行に関するシステム監査で確認した状況
  • 指摘事項
    • システム開発部門内に検証体制を作って移行結果の検証を行い、移行完了としていた
  • • →これは部門内での検証にとどまっており、運用・保守の責任者が確認できていないため指摘事項となる
  • 指摘事項とならないもの
    • 移行作業と併せて、システム運用部門及びシステム利用部門に対する新システムの操作教育を計画し、実行していた
    • 移行対象、移行方法、移行実施体制及び移行スケジュールを明記した以降計画に従って、移行作業を行った
    • 移行ツールを利用して、データベースの移行及び移行結果の確認を行っていた
• 機密性が高い情報を、電子メールを使用して取引先に伝達する方法についての監査で確認した状況
  • 情報漏えい防止の観点から適切なもの
    • 当該情報を記載した添付ファイルにパスワードを設定して、取引先に電子メールを送り、電子メールとは別の手段でパスワードを伝えていること
  • 不適切なもの
    • 自社の公開Webサイトに当該情報を載せ、取引先に電子メールでそのページのURLを伝えていること
    • 当該情報を記載した添付ファイルにパスワードを設定して、パスワードを本文に記載した電子メールを取引先に送っていること
    • 取引先に送る電子メールの本文に、当該情報を記載していること
• 受注管理システムのデータ入力に対するシステム監査の報告書
  • 指摘事項
    • 営業担当者が起票した受注伝票が、直接、受注入力担当者に送られ、受注入力担当者が伝票内容をシステムに入力し、その入力データによって出荷指示が自動的に行われている
  • 指摘事項とならないもの
    • 受注管理責任者と受注入力担当者が任命され、それぞれの役割が職務記述書に明文化されている
    • 受注件数が増えたので、契約社員を受注入力担当者に任命し、営業管理者の承認院のある受注伝票をシステムに入力させている
    • 受注入力担当者がシステムに入力した結果のプルーフリストを、受注管理責任者が出力し、入力した受注伝票と照合している
• 個人情報の取得に関して、JIS Q 15001における個人情報取得時の要求事項への準拠性を監査した
  • 指摘事項
    • Webサイトから注文するシステムにおいて、利用者が申し込みボタンを押し、受注完了画面が表示された時点で、個人情報の利用目的を表示している
  • 指摘事項とならないもの
    • 営業担当者が、顧客から口頭で注文を受ける際、顧客に対して口頭で個人情報の利用目的を伝えている
    • 商品購入者に商品を利用した感想を答えてもらうアンケートはがきに、個人情報の利用目的を記載している
    • 通信販売コールセンタのオペレータが、電話で注文を受ける際、電話を通して顧客に個人情報の利用目的を伝えている
• 個人情報取扱事業者に対する監査において、個人情報の第三者提供の観点
  • 指摘事項に該当するもの
    • フランチャイズの本部から加盟店に、顧客の個人情報を、本人の同意を得ずに渡した
  • 指摘事項とならないもの
    • 社員が意識不明に陥り、家族とも連絡がつかないときに、救急隊員に社員本人の個人情報を、本人の同意を得ずに渡した
    • 税務署の要請によって、従業員の給与振込口座の情報を、本人の同意を得ずに渡した
    • 法令で定められた共同利用に関する事項をWebサイトに明示した上で、プレゼントキャンペーンの応募者データを、本人の同意を得ずにグループ会社と共同利用した
• プログラミングの信頼性に関する監査
  • 指摘事項となるもの
    • プログラマは、プログラムの全てのロジックパスの中から、サンプリングで単体テスト項目を設定している
  • 指摘事項とならないもの
    • プログラマは、プログラム設計書に基づいてプログラミングを行なっている
    • プログラミングチームのリーダは、単体テストの実施結果を記録し保管している
    • プログラムを作成したプログラマ以外の第三者が、単体テストを行なっている
• 請負契約に関する監査
  • 指摘事項となるもの
    • 委託元の管理者が委託先の開発担当者を指揮命令している
  • 指摘事項とならないもの
    • 委託した開発案件の品質を委託元の管理者が定期的にモニタリングしている
    • 契約書に機密保持のための必要事項が盛り込まれている
    • 特定の委託先との契約が長期化しているので、その妥当性を確認している
• ユーザ受け入れテストの監査
  • 指摘事項となるもの
    • システム部門だけでテストを行ない、テスト結果をその責任者が承認した
  • 指摘事項とならないもの
    • 当該業務に精通したユーザが参画してテストを行った
    • ユーザ受け入れテストの実施環境は本番環境と隔離させた
    • ユーザ要求をすべてテスト対象としたテストケースを設定した
• スプレッドシートの利用に係るコントロールの監査において把握した、利用者による行為
  • 指摘事項となるもの
    • スプレッドシートに組み込まれたロジックを、業務上の必要に応じて、随時、変更し上書き保存していた
  • 指摘事項とならないもの
    • スプレッドシートに組み込まれたロジックの正確性を、検算によって確認していた
    • スプレッドシートにパスワードを付した上で、アクセスコントロールが施されたサーバに保管していた
    • スプレッドシートを所定のルールに従ってバックアップしていた
• 内部統制に関する監査
  • 規定が適切に定められていること
    • 規定を確認する
  • 規定が守られていること
    • 申請書やログを付きあわせて確認する
• システム監査実施における被監査部門の行為
  • 適切なもの
    • 監査部門から要求されたアンケート調査に回答し、監査の実施に先立って監査部門に送付する
  • 不適切
    • 監査部門から提出を要求された証憑の中で存在しないものがあれば、過去に遡って作成する
    • システム監査で調査すべき監査項目を自ら整理してチェックリストを作成し、それに基づく監査の実施を依頼する
    • 被監査部門の情報システムが抱えている問題を基に、自ら監査テーマを設定する
• システム監査人の行為
  • 適切なもの
    • 調査によって発見した問題点について、改善指摘を行った
  • 不適切
    • 調査が不十分な事項について、過去の経験に基づいて監査意見をまとめた
    • 調査の過程で発見した問題点について、その都度、改善を命令した
    • 調査の途中で当初計画していた期限が来たので、監査報告書の作成に移った
• システム監査基準(平成30年)に基づいて、監査報告書に記載された指摘事項に対応する行為
  • 不適切なもの
    • システム監査人が、監査対象部門の改善計画を作成する
  • 適切
    • 監査対象部門が、経営者の指摘事項に対するリスク受容を理由に改善を行わないこととする
    • 監査対象部門が、監査対象部門の改善計画を作成する
    • システム監査人が、監査対象部門の改善実施状況を確認する
• アクセス制御を監査するシステム監査人の行為
  • 適切なもの
    • データに関するアクセス制御の管理規定を閲覧した
    • データに関するアクセス制御の管理状況の確認
  • 不適切
    • ソフトウェアに関するアクセス制御の管理台帳を作成し、保管した
    • ネットワークに関するアクセス制御の管理方針を制定した
    • ハードウェに関するアクセス制御の運用手続きを実施した
• システム監査で実施するヒアリング
  • 適切
    • ヒアリングで非監査部門から得た情報を裏付けるための文書や記録を入手するよう務める
  • 不適切
    • 監査対象業務に精通した被監査部門の管理者の中からヒアリングの対象者を選ぶ
    • ヒアリングの中で気が付いた不備事項について、その場で被監査部門に改善を指示する
    • 複数人でヒアリングを行うと記録内容に相違が出ることがあるので、1人のシステム監査人が行う
• 情報システム部が開発して経理部が運用している会計システムの運用状況を、経営者からの指示で監査することになった場合におけるシステム監査人についての記述
  • 適切
    • 独立性を担保するために、システム監査人は情報システム部にも経理部にも所属しない者とする
  • 不適切
    • 会計システムは企業会計に関する各種基準に準拠すべきなので、システム監査人を公認会計士とする
    • 会計システムは機密性の高い情報を扱うので、システム監査人は経理部長直属とする
    • システム監査を効率的に行うために、システム監査人は情報システム部長直属とする
• ”情報セキュリティ監査基準”に基いて情報セキュリティ監査を実施する場合、監査の対象、及びコンピュータを導入していない部署における監査実施の要否の組合せ
  • 監査の対象：情報資産
  • 要否：必要
• その他
  • 情報戦略についてのシステム監査を行う場合、優先して監査すべき事項
    • 経営戦略との整合性を考慮しているか
  • ソフトウェアパッケージ購入に関する監査において監査人自身が行う手続き
    • ソフトウェアパッケージに適合するハードウェア性能の検討が行われていることを確認する
  • システム開発プロジェクトにおける進捗管理の妥当性を確かめるための監査手続き
    • プロジェクト会議の議事録を閲覧し、開発スケジュールと現状との再分析を行い、問題に対して適切な対策が講じられていることを確かめる
  • 顧客サービスの運用業務において、システム監査を受ける際の運用責任者の対応
    • トラブルに関しては、発生から復旧まで電子メールでやり取りした結果を保管し、管理表にはトラブルの対応、発生日および復旧日を記入するルールとなっている。監査人から内容を聞かれたので、電子メールの内容をルールに従って答えた
  • EUCの監査
    • クライアントサーバ環境では、サーバ管理者の役割が重要なので、サーバ管理者に対するヒアリングは必須である
  • 企業の内部監査の一環で実施されるシステム監査
    • システム部門以外の者が、システム部門での業務がルールどおりに実施されているかを、チェックシートを使用して確認した
  • ”ソフトウェア管理ガイドライン”への準拠性を確かめることを目的とした監査
    • ソフトウェアの違法複製を防止・発見する対策事項の監査
  • システム障害管理の監査で判明した状況のうち、監査人が監査報告書で報告すべき指摘事項
    • システム障害の種類や発生箇所、影響度合いに関係なく、共通の連絡・報告ルートが定められている
  • インプットコントロールの監査において、エディットバリデーションチェックが正しく機能しているかどうかを検証する方法
    • 実際に例外データや異常データの入力を行う
  • システム開発委託先(受託者)から委託元(委託者)に納品される成果物に対するユーザ受入テストの適切性を確かめるためのシステム監査の要点
    • 受託者から納品された成果物に対して、委託者が要件定義に基づきユーザ受入テストを実施していること
  • アジャイル開発を対象とした監査の着眼点
    • 業務システムの開発チームは、実装された機能について利害関係者へのデモンストレーションを実施し、参加者からフィードバックを得ていること
  • 人事給与システムのシステム監査において、勤怠データの入力漏れを発見するコントロールの評価項目
    • 入力された内容がプロー不リストとして出力され、人事部の管理者が入力原票と照合を行っていること
  • 販売管理システムにおいて、起票された受注伝票が漏れなく、重複することなく入力されていることを確かめる監査手続
    • プルーフリストと受注伝票との照合が行われているか、プルーフリスト又は受注伝票上の照合印を確かめる
  • ”システム管理基準”に基いて、システムの信頼性、安全性、効率性を監査する際に、システムが不正な仕様から保護されているかどうかという安全性の検証項目
    • アクセス管理機能の検証
  • インプットコントロールの監査で、エディットバリデーションチェックが正しく機能しているかどうかの検証方法
    • 実際に例外データや異常データの入力を行う
  • 業務データのバックアップが自動取得されている場合、日次バックアップデータが継続的に取得されているかどうかをシステム監査人が検証する手続き
    • バックアップジョブの設定内容及びジョブの実行結果ログの閲覧
  • 特権ID(システムの設定、データの操作、それらの権限の設定が可能なID)の不正使用を発見するコントロール
    • 特権IDの貸出し及び返却の管理簿と、特権IDの利用ログを照合する
  • システム監査において、電子文書の真正制の検証に電子証明書が利用できる公開鍵証明書取得日、電子署名生成日及び検証日の組合せ(なお、公開鍵証明書の有効期限は4年間とし、当該期間中の公開鍵証明書の更新や執行は考慮しない前提とする)
    • 公開鍵証明書取得日2015年4月1日
    • 電子署名生成日2015年5月1日
    • 検証日2018年12月1日
  • システムの開発、運用及び保守を担当者が1人だけで実施している企業におけるシステム監査
    • システム改修時の利用部門による動作確認及び責任者による承認の実施状況を確認できる監査手続にする
  • 企業において整備したシステム監査規定の最終的な承認者
    • 経営者
  • ITに係る内部統制を評価し検証するシステム監査の対象となるもの
    • 販売部が行っているデータベースの入力・更新における正確性確保の方法
  • 日本公認会計士協会の監査・保証実務委員会実務指針第66号”受託業務係る内部統制の保証報告書”に基いて作成される文書と作成者の適切な組合せ(ここで、受託業務の一部について再受託が行われており、除外方式を採用しているものとする)
  • 保証報告書：監査人
  • システムに関する記述書：被監査会社(受託会社)
  • 受託会社確認書：被監査会社(受託会社)
• JIS Q 19011:2012における第二者監査に該当するもの
  • 業務委託先である子会社へのシステム監査
  • 指摘事項となるもの
    • システム開発の基本設計工程におけるデザインレビューの参加者を、基本設計担当者、詳細設計担当者、及び開発チームリーダの3者としている
    • A社のシステム開発課長の指揮監督下でB社のプログラマが開発する形態の契約を行う場合、派遣契約であり、B社のプログラマがA社の著作権を侵害した場合の措置に関する規定を設けておく必要がある
    • 提案依頼書(RFP)によるベンダ選定手続きに関して、RFP発行後、問い合わせをしてきたITベンダに対して追加資料を提供していた
  • 指摘事項とならないもの
    • 新システムへの移行の際、移行作業と併せて、システム運用部門及びシステム利用部門に対する新システムの操作教育を計画し、実施していた
    • 提案依頼書(RFP)に、システム化要求事項のほか、あるべき業務モデルも添付していた
    • 提案を希望するITベンダを集めて、提案依頼書(RFP)説明会を実施していた
    • 予算額の範囲を、提案依頼書(RFP)に明示していた

リファクタリング(refactoring)

• バグがなくても、コードの効率や保守性を改善していくこと
• 外部から見た振る舞いを変更せずに保守性が高いプログラムに書き直すこと
• 外部から見たときの振る舞いを変えずに、ソフトウェアの内部構造を変えること
• プログラムの外部仕様を変えずに、内部構造を分かりやすいものに変更すること
• ソフトウェアの動作を変えずに、内部のコードを整理すること
• リファクタリングしたコードは保守性や可読性が高く、再利用性も高くなる
• ソフトウェアの保守性を高めるために、外部仕様を変更することなく、プログラムの内部構造を変更すること
• ソフトウェアの動作を変えずに内部のコードを整理するために以下の作業を行う
  • ソースプログラムを見直して構造化プログラムに変換する
  • ソースプログラムを分かりやすい表現に書き換える
• ソフトウェア開発の活動のうち、アジャイル開発においても重視されている
• リファクタリングしたコードは、保守性や可読性が高く、再利用性も高くなる

DNSキャッシュポイズニング攻撃(DNS cache poisoning)

• 偽装リプライの一種
• DNSサーバからの名前解決要求に対して不正な名前解決情報を付加して返すことでDNSのキャッシュを汚染し、ユーザを悪意あるサイトに誘導する攻撃
• DNSの送信元ポート番号とトランザクションIDが推測されやすいと、この攻撃による被害を受けやすい
• DNSサーバには問合せがあり検索したドメインのIPアドレスを一時的に記憶(キャッシュ)する機能があり、DNSキャッシュポイズニングはこのキャッシュ情報をDNSサーバのセキュリティホールを利用して書換え、DNSサーバの利用者からの問合せに対し偽の情報を返すようにすることで、PC利用者を偽装されたWebサーバに誘導する攻撃方法
• PCが参照するDNSサーバに偽のドメイン情報を注入して、利用者を偽装されたサーバに誘導する
• DNSサーバのキャッシュを不正に書き換えて、インターネットバンキングに見せかけた偽サイトをWebブラウザに表示させる
• PCが問合せを行うDNSキャッシュサーバに偽のDNS応答を送ることによって、偽のドメイン情報を注入する
• インターネット上の特定のWebサーバを参照する場合に、本来とは異なるWebサーバに誘導される
• 例
  • 企業のDMZ上で1台のDNSサーバを、インターネット公開用と、社内のPC及びサーバからの名前解決の問合わせに対応する社内用とで共用しているとき、このDNSサーバが、DNSキャッシュポイズニング攻撃を受けた場合、直接引き起こされ得る現象
    • 社内の利用者が、インターネット上の特定のWebサーバにアクセスしようとすると、本来とは異なるWebサーバに誘導される
• 対策
  • 再帰的な問い合わせに対しては、内部ネットワークからのものだけに応答するように設定する
  • DNS問合せに使用するDNSヘッダ内のIDを固定せずにランダムに変更する

情報セキュリティ

• 情報セキュリティとは機密性（コンフィデンシャリティ）、完全性（インテグリティ）、可用性（アベイラビリティ）を確保、維持していくことである
• 情報セキュリティは、気密性、完全性、可用性を維持し、さまざまな脅威から情報資産を守ることが基本となるため、組織的・人的・物理的・技術的にさまざまな対策を講じる必要がある
• 情報セキュリティ対策には、抑止・抑制、予防・防止、検知・追跡、回復などの機能があり、情報セキュリティ対策は、これらの機能のうち必ず一つ以上の機能をもっている
• セキュリティの特性
  • 機密性、完全性、可用性の三つがある
  • 真正性、責任追跡性、否認防止、信頼性を付加的な特性とする場合がある
  • 機密性
    • 「認可されていない個人、エンティティまたはプロセスに対して、情報を使用不可または非公開にする特性」(JIS Q 13335-1:2006)
  • 完全性
    • 「資産の正確さ及び完全さを保護する特性」(JIS Q 13335-1:2006)
    • 情報や情報処理の方法が正確で完全であるようにすることで、「情報の処理方法の正確さ」とは、情報が誤って削除または変更されないようにすることであり、「情報が完全である」とは、情報や情報システムを無断で改ざんまたは変更されないようにすることを意味する
  • 可用性
    • 「認可されたエンティティが要求したときに、アクセス及び使用が可能である特性」(JIS Q 13335-1:2006)
    • 保持に支障が出る事例：アクセスの集中により、Webサイトの閲覧が不可能になったり、コンピュータウイルスの感染により、データが破壊されて使えなくなってしまう
    • 情報セキュリティに関して発生したインシデントのうち、可用性が損なわれる直接の原因となったもの
      • 空調の故障で温度が上がり、サーバが停止した
  • 真正性
  • 責任追跡性
  • 否認防止
  • 信頼性
    • 「意図した動作及び結果に一致する特性」(JIS Q 13335-1:2006)
• セキュリティの分類
  • 物理的セキュリティ
  • システム的セキュリティ
  • 管理的セキュリティ
  • 人的セキュリティ
• セキュリティの機能
  • 制御機能
  • 防止機能
  • 探知機能
  • 回復機能
• 資産、脅威、脆弱性、リスクの関係を示す概念図
• リスクアセスメント
  • 情報セキュリティ対策の効果を高めるためには、リスク分析によって組織に内在する様々な情報リスクを洗い出すとともに、その影響度を分析、評価し、有効な対策を導き出す取り組み
• 詳細リスク分析
  • 分析の対象となる組織や情報システムにおける情報資産、脅威、脆弱性を洗い出し、それらの関連性からリスクを洗い出し、その大きさを評価する
• 組織の重要な情報資産を適切に保護するためには、その重要度などに応じて整理、分類するとともに、取扱い方法を明確にする必要がある

LRU(Least Recently Used)

• 仮想記憶の管理のページ入れ替え方式の一つ
• 仮想記憶管理のページ入れ替え方式のうち、最後に使われてからの経過時間が最も長いページを入れ替える
• 最近参照されていないページは近い将来にも参照される可能性が小さいという推測に基づいて、最後に使われて から(参照されてから)の経過時間が最も長いページ（最終参照時刻が最も古いもの）を置き換える
• ページ置き換えの判断基準に最後に参照した時刻を用いる
• 最後に参照されてから経過時間が最も長いページを置き換える方式
• 最も長い間参照されていないページを置き換える
• もの
• LRUアルゴリズムは、使用後の経過時間が最長のページを置換対象とするページ置換アルゴリズムである
• キャッシュメモリと主記憶との間でブロックを置き換えるとき、置き換えの対象になるブロック
  • 最後に参照されてから最も長い時間が経過したブロック

データベースの運用

• データベースの運用では、正常時の運用だけではなく、障害時にどのように回復するかをあらかじめ決めておくことが重要
• 障害の種類と回復方法
  • トランザクション障害
    • トランザクションの異常終了や0除算、デッドロックなどによるトランザクション障害が発生した場合、ログファイルの更新前情報を利用してロールバック(後退回復、UNDOともいう)処理を行い、トランザクション開始前の状態に戻す
  • 媒体障害
    • ディスククラッシュなどの媒体障害が発生した場合、記憶媒体を交換してバックアップデータをロード(リストア)した後、ログファイルの更新後情報を利用してロールフォワード(前進復帰、REDOともいう)処理を行い、障害が発生する直前の状態に戻す
  • システム障害
    • システムダウンや電源断といったシステム障害が発生した場合、再起動したシステムは「バッファの情報は失われているが、データベースには一部の処理結果が反映された状態」となる
    • データベースを最新のチェックポイントまで戻してから、次のような処理を行う
      • チェックポイントから障害発生までの間にコミットされたトランザクションについては、チェックポイントからロールフォワードを行い、処理を完了させる
      • チェックポイント以前に開始され、障害発生までの間にコミットされていないトランザクションについては、チェックポイントからさらにロールバックし、処理開始前の状態に戻す
      • 最新のチェックポイント以前にコミットされたトランザクションについてはデータベースに更新内容が反映されているので、障害回復を行う必要はない

IP電話

• R値
  • IP電話の音声品質を表す指標のうち、ノイズ、エコー、遅延などから算出されるもの
• ゲートキーパ
  • 電話番号とIPアドレスの対応を管理することを主たる機能とする装置
• MOS値
  • 電話の音声の品質を評価するための手法の1つで、人間の耳で音声の良し悪しを判断するという主観的な測定方法
• IP電話サービス
  • インターネット電話と同じVoIP技術が用いられるが、一般に総務省の定める電気通信役務として規制を受けるものをIP電話サービスと呼ぶ
• SIPサーバ
  • IP電話を実現するために、一般の電話サービスが持つ基本的な呼制御機能のほか、着信機能、転送機能、発信し番号通知機能などを実現する装置
  • ユーザエージェント相互間で、音声や映像などのマルチメディア通信のセションの確立、変更、切断を行う
• IP電話の品質
  • ネットワーク品質の影響を受けやすく、一般のPSTNに比べて通話品質が落ちる場合がある
  • 遅延
    • 自分が話し始めてから相手に聞こえ始めるまでの時間の遅れ
    • 遅延が大きくなるほど相手とスムーズに会話できなくなる
  • ジッタ
    • 音声データの入ったIPパケットの到着時間がばらつく現象
    • 音声データが到着する時間間隔が長くなると、IPパケットから音声を復元するためのジッタバッファを大きく設定する必要が発生し、再生される音声の遅延を増加させる
  • パケットロス
    • 音声パケットが消失する現象
    • 消失した部分の音声データがないため、相手側では正しく音を再生できない
  • R値
    • 雑音、遅延エコーなどを考慮し、一定の式から算出される総合的な音声品質指標
  • MOS
    • 複数の評価者が品質を5段階で評価して平均を求める通話品質の主観評価法
  • 客観評価法
    • リファレンス音声(原音)と評価対象音声の劣化を一定のアルゴリズムで評価する
    • PESQやPOLQAなど

IPアドレス(IPv4)

• 32ビットのアドレスであり、8ビットごとにピリオドで区切り、10進数で表記する
• 32ビットを、ネットワーク部とホスト部に分けることで、どのネットワークのどのホストであるかを識別できるようになっている
• ネットワーク部とホスト部は、従来はクラスという概念で区切られていたが、最近ではサブネットマスクを用いてネットワークを複数のサブネットワークに分割し、IPアドレス空間の有効利用や運用負荷の分散を図る場合が多い
• サブネットマスクを用いてホスト部の一部をネットワークの一部(サブネットの識別子)として扱う
• サブネットマスクは32ビットのマスク(ビットパターン)であり、ネットワーク部に該当する部分には1を、ホスト部に該当する部分には0を設定し、IPアドレスと同様に8ビットごとにピリオドで区切り、10進数で表記する
• 32ビットのIPアドレス(IPv4)は、世界的なインターネットの普及に伴って枯渇しつつあり、この問題を解決する方法として、IPv6と呼ばれる後継規格が策定されている
  • IPv6
    • IPアドレスの128ビットか(アドレス数がIPv4の2⁹⁸倍)
    • ルータから通知される情報と自身が生成する情報からアドレスを自動生成するプラグアンドプレイの実現
    • IPsecを標準機能とするセキュリティ機能の充実

PPP(Point to Point Protocol)

• WANを介して二つのノードをダイヤルアップ接続するときに使用されるプロトコルで、リンク制御やエラー処理機能をもつ
• WANを介して二つのノードをダイヤルアップ接続するときに使用されるプロトコル
• 認証機能や圧縮機能をもち、2点間を接続する通信プロトコル
• ２拠点間を電話回線などで接続するための規格
• リモートアクセス用のプロトコル
• インターネットへのダイアルアップや遠隔地LANへの接続に使われ、PAPやCHAPなどの認証機構を持っている
• アクセス経路としては公衆回線網を想定しているが、インターネット上で使うPPPoEなど多くのバリエーションがある
• PPPの認証技術
  • PAP
    • 最も基本的な認証プロトコル
    • パスワードを平文で送る
  • CHAP
    • チャレンジレスポンス方式を使うことで、ネットワーク上にパスワードを送信しない工夫がされた認証プロトコル
  • EAP
    • PPPでは、PAPかCHAPを使うことが想定されていたが、CHAPの脆弱性の指摘によりEAPが利用されるようになった
    • 認証方式を複数から選べるようになっている
    • EAP-TLS、MS-CHAP、LEAP、PEAP、EAP-MD5など

Webアプリケーションの脆弱性

• URLパラメタ、hiddenフィールド、クッキーのいずれかの手段でセッション管理を行うが、それらのうちどれを用いていたとしても、HTTPで通信していればセッション管理情報の漏えいが発生する可能性がある
• クッキーの有効期限は可能な限り短く、また有効範囲は可能な限り狭くすることに加え、HTTPS(TLS)を使用しているページでは必ずsecure属性を設定し、登頂によってクッキーが盗まれるのを防ぐ必要がある
• Http Only属性をクッキーに設定することにより、適用範囲をHTTP/HTTPS通信だけに限定し、XSSによってクッキーが盗まれるのを防ぐことが可能となる
• 重要なセッション管理情報はすべてのWebサーバ側で管理し、URL、パラメタ、クッキー、hiddenフィールドには、セッションの識別情報(ID)しか含めないようにする
• セッションIDには十分な長さをもった乱数やハッシュ値を用いる
  • GETメソッドを使用している場合には特に重要
• HTTPベーシック認証では登頂によって認証情報が漏えいする可能性があるため、使用する場合にはHTTPSよって暗号化する
• Webサーバが詳細なエラーメッセージをクライアントに返す設定となっていると、機密情報の漏えいにつながる可能性があるため、必要最小限のエラーメッセージのみを変えすように設定する

類推見積り

• 類似法、類似見積り法、類推法ともいう
• システム開発の見積方法の一つ
• 過去に開発した類似したシステムの経験や数値から開発工数を見積もる方法
• 経験豊富なメンバが必要
• トップダウン見積もりの一つで、全体規模を見積もり、各サブシステムに所要開発量を割り振る
• 一種の直感であり、各作業の見積り工数を積み上げたものではない
• 精度が高くなる場合
  • 見かけだけでなく実質的に類似している場合
  • 見積りを実施する担当者が必要な専門知識を有する場合
• 過去に経験した類似のシステムについてのデータを基にして、システムの相違点を調べ、同じ部分については過去のデータを使い、異なった部分は経験から規模と工数を見積もる方法である
• 過去に経験した類似のソフトウェアについてのデータを基にして、ソフトウェアの相違点を調べ、同じ部分については過去のデータを使い、異なった部分は経験に基づいて、規模と工数を見積もる方法である
• 類似のプロジェクトにおける過去のコスト実績を使って、プロジェクトのコストを見積もる
• 過去の経験や類似のプロジェクトを基に類推する見積方法
• 過去の同様のプロジェクトや、標準的なプロジェクトから、プロジェクトやアクティビティのコストや所要期間を推定する方法
• 推定方法の例
  • 経験者が過去の経験から自分の感覚で見積もる
  • 企業などで準備している標準的な開発方法のテンプレートに合わせて計算する
• 開発した情報システムを他の部署に横展開するなどの過去に同様のプロジェクトが存在している場合や、類似のプリケーション業務や開発手法のデータが十分に蓄積されている場合に適している
• 個人の経験や主観に頼るところが多いので、新技術を取り入れた情報システムや大規模なプロジェクトでは、十分な見積り精度を得るのは難しい

ブレーンストーミング

• 問題解決手法の一つ
• 参加者のアイデアを批判することなく、またそのアイディアから新たなアイディアを導き出そうとする創造的問題解決に適した技法
• 自己の創造的アイデアを思いつくままに出していき、集団の集中的ディスカッションによって、考えをより発展させようとするもの
• 批判厳禁、自由奔放、質より量、他人の意見の活用などを基本ルールとして、多様で新たな意見を収集する
• 参加者を一か所に集め、進行役の下で、誰かの意見から別の意見を引き出すなどしながら、次々にアイデアを集める
• 出されたアイデアの評価をせず、できるだけ自由に発想させる手法
• ルール
  • OK
    • 突飛なアイディアも含め、自由奔放な発言を歓迎する
  • NG
    • 各自でアイディアを練り、質が高いと思うものだけを選別して発言する
    • 他人が出したアイディアを遠慮なく批判する
    • 他人の出したアイディアに改良を加えた発言は慎む

デルファイ法

• 多数の専門家に同一内容のアンケート調査を繰り返すことによって意見をまとめる方法
• 前回のアンケート結果を要約して回答者にフィードバックし、回答者が全体の意見をもとにして回答内容を修正できる
• 結果が収束するまで調査および結果の回収を繰り返す
• 専門化に対するアンケートを繰り返す手法
• 予測手法の一つ
• 複数の専門家へのアンケートの繰り返しによる解答の収束によって将来を予測する
• 他の技法では答えが得られにくい、未来予測のような問題に多く用いられる予測技法
• 手順
  1. 複数の専門家を回答者として選定する
  2. 質問に対する回答結果を集約してフィードバックし、再度質問を行う
  3. 回答結果を統計的に処理し、分布とともに回答結果を示す
• 専門家に対して、アンケート調査を繰り返し行って意見を集約させていく問題分析技法
• 参加者は同席する必要がなく、文書でのやり取りなので電子メールなどでも利用できる
• 進行役が複数の専門家に主要なプロジェクトリスクに関しての質問表を送り、書面による回答を得る
• 得られた意見を匿名で取りまとめたものを再び専門家たちに配布し、追加の意見やコメントを集める
• これを繰り返すことで、専門家たちの合意を得る
• 偏見が入りにくく、結論に関して特定の人の強い影響を受けるということのない方法
• 参加者にテーマだけを提示し、そのテーマに対し、意見の収集、要約、配布、再度の意見の収集を繰り返すことで、集約した意見を収集した
• 現在の動向から未来を予測したり、システム分析に使用したりする手法であり、専門知識や経験を有する複数の人にアンケート調査を行い、その結果を互いに参照した上で調査を繰り返して、集団としての意見を収束させる手法
• 専門家がそれぞれ独自に意見を出し合い、相互参照を行って再び意見を出し合う、という作業を数回行い、意見を収斂させていく方法
• 未来予測などで使われる
• 他の技法では答えが得られにくい、未来予測のような問題に多く用いられる
• 何回も同じパネル(回答者)に反復調査する
• 予測手法の一つ
• 複数の専門家へのアンケートの繰返しによる回答の収束によって将来を予測する
• 将来の科学技術の進歩の予測などについて、専門家などに対するアンケートを実施し、その結果をその都度回答者にフィードバックすることによって、ばらばらの予測を収束させる方法
• 現在の動向から未来を予測したり、システム分析に使用したりできる手法
• 現在の動向から未来を予測したり、システム分析に使用したりする手法であり、専門的知識や経験を有する複数の人にアンケート書調査を行い、その結果を互いに参照した上で調査を繰り返して、集団としての意見を収束させる手法
• 質問に対する回答の結果を、すべての回答者へフィードバックすることを繰り返すことによって、集団の意見を集約する手法
• 現在の動向から未来を予測したり、システム分析に使用したりする手法
• 専門的知識や経験を有する複数の人にアンケート調査を行い、その結果を互いに参照した上で調査を繰り返して、集団として意見を収束させる手法
• 集団の意思を相対させながら調査を繰り返して、意見を収束させる手法
• リスク識別に使用する技法の一つ
• 複数の専門家から得られた匿名の見解を要約して、再配布することを何度か繰り返して収束させる
• 手順
  1. 専門的知識や経験を有する複数の専門家を回答者として選定する
  2. 専門家の直感や推量によって得られた質問に対する回答結果を、フィードバック、整理し、再度質問を行う
  3. 回答結果を統計的に処理し、確率分布とともに回答結果を示す
• プロジェクトのリスクを、デルファイ法を利用して抽出しているもの
  • 複数のお互いに関係がないステークホルダやプロジェクトマネージャにアンケートを行い、その結果を要約する。さらに、要約結果を用いてアンケートを行い、結果を要約することを繰り返してリスクをまとめる

SOA(Service Oriented Architecture;サービス指向アーキテクチャ)

• 業務機能を提供するサービスを組み合わせてシステムを構築すること
• 業務機能を提供するサービスを組み合わせることによって、システムを構築する考え方
• 業務上の一処理に相当するソフトウェアの機能をサービスとして実装し、それらのサービスを組み合わせてシステム全体を構築するという考え方
• 再利用可能なサービスとしてソフトウェアコンポーネントを構築し、そのサービスを活用することで高い生産性を実現するアーキテクチャ
• ビジネスプロセスの構成要素とそれを支援するIT基板を、ソフトウェア部品であるサービスとして提供するシステムアーキテクチャ
• サービスを設定する際の注意点
  • 業務の変化に対応しやすくするために、サービス間の関係は疎結合にする
• ユーザに提供するサービスの集まりとして、システムを構築する考え方
• ある情報システムの構築において、ビジネスプロセス上の独立した業務機能という視点で部品化して情報システムを構築し、将来の変更や他の情報システムの開発に、それらの部品を用意に利用できる仕組みを作り上げる考え方
• 利用者の視点から各業務システムの機能を幾つかの独立した部品に分けることによって、業務プロセスとの対応付や他のソフトウェアとの連携を容易にする手法
• ビジネスプロセスの構成要素とそれを支援するIT基板を、ソフトウェア部品であるサービスとして提供するシステムアーキテクチャ
• サービスというコンポーネントからソフトウェアを構築することによって、ビジネス変化に対応しやすくなる
• ソフトウェアの機能をサービスという部品とみなし、そのサービスを組み合わせることによってシステムを構築する概念のこと
• 業務機能を提供するサービスを組み合わせることによって、システムを構築する考え方
• 業務システムの機能を、利用者の観点から複数の独立したソフトウェア部品に分割し、業務機能を提供するサービス(ソフトウェア部品)を組み合わせることによってシステムを構築する考え方
• 「受注」「出庫」といったビジネス上のプロセスを組み合わせ、利用者が業務の目的にあわせて必要なサービスを実行できるようにする
• ソフトウェアの機能をサービスという部品とみなし、そのサービスを組み合わせることによってシステムを構築する概念のこと
• 利用者の視点から業務システムの機能を幾つかの独立した部品に分けることによって、業務プロセスとの対応付けや他ソフトウェアとの連携を容易にする手法
• システムを構成する個々のアプリケーションソフトウェアを利用者が享受するサービスと捉え、サービスを組み合わせることによってシステムを構築する設計思想
• サービスというコンポーネントからソフトウェアを構築することによって、ビジネス変化に対応しやすくする
• SOAでシステムを設計する際の注意点
  • 業務の変化に対応しやすくするために、サービス間の関係は疎結合にする
• ESB
  • SOAにおいて、異なるアプリケーションソフトウェアやコンポーネントの間でのデータのやり取りを行うために、データ形式の変換、データの振り分け、非同期連携などの機能を実現するもの

(一覧)価格戦略

• コストプラス価格決定法
• スキミングプライシング
  • 製品を投入した初期段階で、高い価格を設定する価格戦略の手法
  • 先行者利益を獲得し、早期に資金を回収することを目的とする
• ペネトレーションプライシング
• バリュープライシング
  • 顧客が適切な価格と認識できるような、購買意欲を高める価格を設定する手法
• サブスクリプションプライシング
  • 利用用金を支払うことで一定期間の利用権を得て、製品やサービスを使用することができる方式

セキュリティホール

• プログラムの実装あるいは設計上のバグ

脅威

• 人為的脅威
  • 人間の行為によって発生する
  • 偶発的脅威
    • 偶然発生する脅威で、エラーや不注意など
  • 意図的脅威
    • 盗難や不正利用など、人間により故意に行われる脅威
• 環境的脅威
  • 自然災害や経年劣化による故障といった環境によって自然に発生する

リスクコントロール

• 潜在的なリスクに対して、物理的対策、技術的対策、運用管理的対策によって、発生を抑止したり、損失を低減させたりすること

クラス図

• UMLのクラス図は、データモデルを表現するために用いられる
• クラス、関係、多重度などで表現する
• 多重度
  • クラス間の関係に対して、それぞれのクラスにどれだけインスタンスがあるのかを示す数値
  • 実数、＊(上限が無いことを示す)、値の範囲(「m..n」m以上n以下)などを用いて表す

(一覧)ブランド戦略

• ラインエクステンション
• カテゴリエクステンション

(一覧)開発プロセス

(一覧)ISO/IEC 9126

• JISではJIS X 0129-1
• ソフトウェアの品質特性

  品質特性	品質副特性
  機能性	合目的性
  	正確性
  	相互運用性
  	セキュリティ
  	機能性標準適合性
  効率性	時間効率性
  	資源効率性
  	効率性標準適合性
  信頼性	成熟性
  	障害許容性
  	回復性
  	信頼性標準適合性
  保守性	解析性
  	変更性
  	安定性
  	試験性
  	保守性標準適合性
  使用性	理解性
  	習得性
  	運用性
  	魅力性
  	使用性標準適合性
  移植性	環境適応性
  	設置性
  	共存性
  	置換性
  	移植性標準適合性

データベースの設計

• データベースの設計においてはシステム化の対象となる現実世界をE-Rモデルなどで表現するデータモデルの作成(データモデリング)が重要となる
• データ分析
  • データの識別(どのようなデータが必要か)
  • データ項目の定義(データがどのような意味を持つか)
  • データ項目の標準化(他のデータとどのように関連するか)
• データモデルの作成
  • トップダウンアプローチ
    • 要求から概念データモデルを作成し、属性の洗い出し、正規化を行い、データモデルを作成する
  • ボトムアップアプローチ
    • 画面や帳票からデータ項目の収集・定義を行い、正規化、データ項目の分割を行い、概念データモデルを作成する

電子メールの脆弱性

• 広く普及しているメールサーバソフトウェアの旧バージョンでは、メールの投稿にあたってユーザを認証する仕組みがなかったため、発信元メールアドレスの詐称が堂々と行われるほか、組織外の第三者から別の第三者へのメール投稿を受け付け、中継してしまう

価格戦略

• 価格を決定する際には、価格弾力性を考慮する
• 価格弾力性
  • 価格が需要に及ぼす影響を測る指標
  • $価格弾力性=\cfrac{受容の変化率}{価格の変化率}$
  • 価格弾力性が1であれば、価格の変化によって受容が同水準で変化することを表す
  • 1より小さければ価格が需要に与える影響は少なく、1より大きければ需要に大きな影響を与えることを示す

メール送信時のセキュリティ対策

• メールのなりすまし対策
  • POP before SMTP
    • SMTPに手を加えずに認証を行えるよう工夫したプロトコル
    • SMTPによる送信に先立ってPOPの認証機構を使ってパスワードを確認し、そのIPアドレスに対して一定時間のSMTP接続を許可する
    • POPはユーザを認証しているだけなので、そのIPアドレスからのメール送信を許可するのが、必ずしも正しくない場合がある
    • メールクライアントからメールサーバへの電子メール送信は、POP接続で利用者認証済の場合にだけ許可する
  • SMTP-AITH
    • SMTPに認証機構を組み込んだプロトコル
    • ユーザIDとパスワードによる認証を行う
    • 従来のSMTPと互換性がないので、クライアント側、サーバ側がともにSMTP-AUTHに対応していないと利用することができない
    • SMTPに直接認証機構が組み込まれることで、より高い水準のセキュリティが実装される
    • メールクライアントからメールサーバへの電子メール送信時に、利用者IDとパスワードによる利用者認証を行う
  • 送信ドメイン認証
    • 発信元情報を偽装したメールを発見し、排除する技術
    • 発信元のIPアドレスやディジタル署名によってメール受信側で発信元SMTPサーバを認証する仕組み
    • 受信した電子メールが正当な送信者から送信されたものであることを保証する技術
    • サーバ側だけで対策できる認証方法
    • 送信ドメイン認証による迷惑メールの判定方法
    • 電子メールが正規のメールサーバから送信されていることを検証し、迷惑メールであるかどうかを判定する
    • SPF(Sender Policy Framework)
      • メールを送信する可能性があるIPアドレスの範囲を、SPF情報としてDNSで公開する方法
      • 受信側メールサーバはDNSに問合せを行い、送信元IPアドレスがSPFで公開されている範囲にあれば席のメールとして受け付ける
      • DNSのTXTレコードに公開
    • DKIM(DomainKeys Identified Mail)
      • 送信側メールサーバがメールに対してディジタル署名を付与する方法
      • ディジタル署名はメールヘッダに挿入され、検証するための公開鍵はDNSでTXTレコードとして公開する
      • 受信側のメールサーバは、この公開鍵を取得してメールを検証する
    • DMARC(Domain Message Authentication, Reporting, and Conformance)
      • SPFやDKIMの仕組みを用いて検証した結果、認証失敗時にメールの処理方法をポリシーとして定義する仕組み
      • 受信者は認証に失敗した場合には送信者のポリシーを参照し、それに基づいてメールをどのように取り扱うかを決定する

MQTT

• IoT用の通信プロトコル