応用情報技術者試験のシステム監査で高得点とるためのまとめ
参考になりそうなサイト
監査人に任命するにあたり確認する独立の観点(R2秋)
- 監査人の所属部門が監査対象と同じ指揮命令系統に属していないこと
- 以前に監査対象の領域または業務に従事していないこと
具体的に確認すべき項目として解答すべきことは
- 担当から離れて一定期間経過していること
- 開発・保守業務に対する関与度合い
など。
監査手続の考え方
「必要な手続」の見つけ方
- 本文を読んで、業務手続き(登録や承認であり監査手続きではない)の手順をまとめる。
- 必要な手続きを見つける
- 見つけた手続きに「記録」をつけるか検討する
監査の結論を裏付けるために十分で適切な監査証拠を手に入れることができるものである必要があります。
不要な権限の見つけ方
- 本文を読んで、業務手続き(登録や承認であり監査手続きではない)の手順をまとめる。
- 誰に何の権限がある・ない・不明をまとめる
- ない・不明の権限が仮に付与されていた場合、1のフローを通さずに業務手続きができてしまうものを選ぶ
その他(本文の単語+本文にない業務動作の単語)
承認権限はあるので、入力権限も付与されていたら不正が可能になる(R2秋)
監査実施の注意点
エラー処理などの監査をする際に、架空のデータを使うことがあります(テストデータ法)。
そのとき注意することは、実在するデータとして処理されないようにすることです。
例：監査人が作成した発注データが受注確定されてしまわないこと
改善が必要になること
担当者が入力と承認を行うことができること
移行作業表を作成するのは開発担当者で、移行するのは以降担当者だが、開発担当者も移行に関する権限が与えれらてしまっているため、場合によっては移行作業表を作成せず移行できてしまう(R1秋)
システムを介さない手続き(R1秋)
「システムの権限設定を見てシステム利用者の職務分離が確保されているか確認する」手続きでは、システムを介さずにデータを入力・修正したものを確認する手段がない
監査手続の技法
インタビュー法
監査対象の実態を確かめるため、システム監査人が直接、関係者に口頭で問合わせ回答を入手する技法
チェックリスト法
システム監査人が、あらかじめ監査対象に応じて作成されたチェックリストに対して関係者から回答を求める技法
突合・照合法
関連する複数の証拠資料間を突き合わせること、記録された最終結果について、原始資料までさかのぼってその起因となった事象と付き合わせる技法
ペネトレーションテスト
システム監査人が一般ユーザのアクセス権または無権限で、テスト対象システムへの侵入をためし、システム資源がそのようなアクセスから守られているかどうかを確認する技法
その他
職務の分離(R3春)
業務の担当者と承認者を分離し、職責と権限を適切に分配することで、各者間での相互牽制を働かせること
ビジネスを有利にはたらくための情報
取引先の見積額
応用情報技術者試験のDB問題で高得点とるためのまとめ
エンティティの考え方
多重度
種類は以下の4つ。この中からどれを選ぶか考え方を考える。
ー：1対1
→：1対多
⇔：多対多
1対多(R2)
これを記述するパターンが1番多い。矢印の向きは主キーから外部キーへの向き。
A(主キー) → A(外部キー)
A(外部キー) ← A(主キー)
⇔：多対多
第3正規形にしないといけないため、多対多を書くことはなさそう。
属性
リレーションシップの矢印の向きと隣り合う属性をみて、判断。
隣り合うエンティティの主キー・外部キーになっているものが、空欄に記述する属性になる。
主キー：テーブルの行を一意に識別する。
隣に主キーがあれば、記述する属性は外部キー。
データウェアハウスでの考え方(あくまでR3)
要件を満たすためのデータモデルを作成するため、分析に不足している属性を本文から抜き出す。
現状のER図のままだとエラーになることが判明した(R1)
主キーが同一のレコードを登録して実行時エラーになるパターンが多そうです。
対応策として、エラー原因となっている表の主キーをみなおし、主キーを別の属性に変更することです。
正規化
第1正規系
テーブル中に複数の値をもつようなデータ項目を含まないよう整理
第2正規系か判断する
「主キーAと主キーBが存在し、非キー属性Cが異なれば主キーAは異なる」
→非キー属性Cは主キーAに関係従属し、主キーBには関係従属しない
なので第2正規系になっていない
第2正規系でなくても問題がない理由
本文に、「テーブルの内容は変更されることはない」と記載されるパターンが多い。
回答例：〇〇テーブルに追加された行の値がその後、変更されることはない
※テーブルの内容(主キー)が変更になった場合、複数の行を同時に変更しないといけないため、更新漏れが発生しそう
第2正規系
第1正規系の表に対して、主キーの一部の項目だけに従属するような項目を含まないよう整理
候補キー
主キーの候補になりうる項目
代替キー
主キー以外の候補キー
非キー属性
候補キー以外の項目
第3正規系
第2正規系の表に対して、主キー以外の項目に従属するような項目を含まないよう整理
SQL文の考え方
どの表が使われているか確認すること！
困ったら本文を探そう。見逃している条件があるかも！
SQLの実行順序
FROM
JOIN
WHERE
GROUP BY
SUMやAVEなど
HAVING
SELECT, DISTINCT
ORDER BY
LIMIT
SELECT 列名(または＊) FROM テーブル名 WHERE 条件式
例：
SELECT COUNT(*) FROM 従業員
SELECT 単価 * 0.5 FROM 商品
細かい条件
SELECT DISTINCT 商品名 FROM 商品
重複を除く
SELECT 年齢, COALESCE(性別,2) FROM 会員
NULL値を別の値に変換する
SELECT 日付, (CASE WHEN 時刻 < 12 THEN 0 ELSE 1 END) FROM 入館
SQL文で条件式を使う
JOIN句
INNER JOIN 結合するテーブル B ON A.属性 = B.属性
両方のテーブルにあるデータのみを取り出す(内部結合)
2つのテーブルにあって、合体できるデータのみを取り出します。
エンティティが1対1のときはこれを使用(R3)
LEFT JOIN 結合するテーブル B ON A.属性 = B.属性
左のテーブルをすべて表示して結合(外部結合)
RIGHT JOIN 結合するテーブル B ON A.属性 = B.属性
右のテーブルをすべて表示して結合(外部結合)
WHERE句による条件設定
WHERE 予約日 BETWEEN '20220306' AND '20220310'
範囲を指定する
WHERE 予約日 IN ('20220306', '20220310')
()内の値が対象
WHERE 名前 LIKE '_太郎%'
_は任意の1桁、%は任意の0～N桁の文字
WHERE 電話番号 IS NULL
NULLを抽出
WHERE 電話番号 NOT IS NULL
否定した条件
GROUP BY句(R3 SELECT文にCOUNTがあればGROUP BY)
SELECT 予約日, SUM(予約人数) FROM 予約明細 GROUP BY 予約日
SUM()以外にはAVG(),MAX(),MIN(),COUNT(*)などがある
GROUP BY句とHAVING句(R2)
SELECT 予約日, SUM(予約人数) FROM 予約明細 GROUP BY 予約日 HAVING COUNT(*) > 3
ORDER BY句
SELECT 予約番号, SUM(金額) FROM 予約明細 GROUP BY 予約番号 ORDER BY 予約番号 ASC
昇順はASC、降順はDESC
副問合せ
- 内側のSELECT文を実行
- 1で取得した値を用いて外側のSELECT文を実行
例：
SELECT 宿泊日, 利用料金 FROM 予約明細
WHERE 顧客コード IN (SELECT 顧客コード FROM 予約 WHERE 担当ID = '100')
相関副問合せ(R2,H31)
EXISTSやNOT EXISTSを使った存在チェックで使用することが多い。
副問合せでは「該当データが存在するかどうか」という結果が分かればいいので、副問合せの列名は「*」を使用する。
- 主問合せを実行する(外側のSELECT文)
- 1で取得した値を用いて副問合せを実行する(内側のSELECT文)
例：
SELECT 施設ID, 部屋種別ID, COUNT(*) FROM 部屋
WHERE NOT EXISTS (
SELECT * FROM 予約明細 WHERE 予約明細.部屋ID = 部屋.部屋ID
AND 予約明細.宿泊日 >= :チェックイン日付 AND 予約明細.宿泊日 < :チェックアウト日付)
AND 施設ID = :施設ID AND 部屋種別ID = :部屋種別ID
GROUP BY 施設ID, 部屋種別ID
HAVING COUNT(*) >= :部屋数
INSERT
INSERT INTO 予約 (氏名, 日付, 担当者, コースコード) VALUES('山田山男', '2022-03-07', '佐藤佐子', '08')
試験問題では、VALUESの値が書かれているケースは少なそう。
INSERT INTO 予約 (コースコード) SELECT DISTINCT 予約 FROM コース
R1
UPDATE
UPDATA テーブル名 SET 列名 = 変更値, ・・・ WHERE 条件式
試験問題では、変更値がSELECT文になっているパターンが多い。
使用しているテーブル名を見て問題に答えること
DELETE
DELETE FROM テーブル名 WHERE 条件式
WITH(H31)
WITH 副問合せ名 AS (クエリ文)：副問合せ名
UNION(H31)
同じ列名が存在する2つのSELECT文をつなぐ
SELECT 列名A FROM テーブルB UNION SELECT 列名A FROM テーブルC
重複は1つにまとめる
SELECT 列名A FROM テーブルB UNION ALL SELECT 列名A FROM テーブルC
重複もそのまま表示する
制約
非ナル制約
ある列にNULLが入らないようにする制約
UNIQUE制約(R2)
指定した列・列の組み合わせが一意であることを強制する制約
主キー制約
指定した列・列の組み合わせに1つだけ主キーを指定
検査制約
指定した列の内容を指定した条件を満足するもののみにする制約
参照制約
参照元テーブルに外部キーを指定する
データウェアハウス設計のスキーマ(R3)
スタースキーマ
1つのファクトテーブルの周囲に、複数のディメンションテーブルが単一の階層で関連付けられる。
ファクトテーブル：分析対象のデータを格納したテーブル
ディメンションテーブル：ファクトテーブルの外部キーから参照する主キーを持つマスタ系テーブル
スノーフレークスキーマ
スタースキーマのディメンションテーブルを正規化(階層化)した構造
データマート(R3)
データウェアハウスに格納されたデータから特定の用途に必要なデータだけを取り出し、構築する小規模なデータベース。
データウェアハウスで分析するのに時間がかかりすぎる場合、データマートを追加する。
つまり「データマートの表を見れば分析できる」という状態がのぞましい。
3層スキーマ
DNSのセキュリティ対策などの考察
DNSのセキュリティ対策について考えます。(参考：R3春 応用情報)
DNSサーバの種類
権威DNSサーバ(DNSコンテンツサーバ)
- ドメインの名前解決の情報を持っている
- 外部からの問合せに対して、自身が保持する情報を応答する。
キャッシュDNSサーバ
- ドメインの名前解決の情報をもたない
- 外部に問い合わせを行って、その結果をクライアントに返す。
- 結果はキャッシュとして一定期間保持する
DNSの名前解決の種類(H30午前)
再帰的な問合せ
リゾルバから名前解決要求をうけたDNSサーバが他のDNSサーバに代理して問い合わせを行い、最終的な結果をリゾルバに返す必要のある問い合わせのこと。
反復問合せ
リゾルバから再帰的問合せを受けたDNSサーバがそれを解決できるまで繰り返し他のDNSサーバに行う問い合わせのこと
SSL証明書とDV・OV・EV
DNSサーバのインシデントの再発防止としてSSL証明書の話があげられていたのでまとめます。
参考：SSL証明書とは？仕組みや種類についてわかりやすく解説 | システム運用ならアールワークスへ
SSLとは
インターネット上の通信を暗号化する仕組みです。
SSL証明書とは
公正な第三者機関である認証局(CA)が、通信先のサーバが実在することを証明し、通信相手に偽りがないことを証明する
SSL証明書に含まれる鍵(公開鍵・秘密鍵)を用いて、ブラウザとサーバ間でやりとりされる通信を暗号化する
ドメイン認証(DV)
ドメイン名の所有者であることが確認できる
企業実在認証・組織認証(OV)
登録簿などを確認し、組織として法的に実在していることが確認できる
EV認証(EV)
上記2つの認証に加え、物理的に組織が存在するか、事業が存在・運営されているか、承認者・署名者が確認できる
DNSキャッシュポイズニング
DNSキャッシュサーバに偽のDNS情報をキャッシュとして登録させ、ユーザに偽サイトへ誘導する攻撃。
DNSキャッシュサーバに偽のキャッシュ情報を登録させる手順
- 攻撃者はキャッシュサーバに対して偽の再帰的な問い合わせを行い、反復問合せを強制的に生じさせる
- キャッシュサーバはコンテンツサーバに対して反復問合せをする
- 攻撃者はコンテンツサーバが正規の応答をするよりもさきにキャッシュサーバへ偽の応答を送りつける
- キャッシュサーバは攻撃者から送り付けられた偽の応答を正規のものと判断し、キャッシュに登録する。
対策
再帰的な問い合わせに対して内部ネットワークからのものに限定する。
DNSSEC
DNSの正当性を保証するための拡張仕様。
公開鍵暗号方式のディジタル署名を用いて、正当なDNSサーバからの応答であることをクライアントが検証する
情報セキュリティ10大脅威2022個人編の考察
情報セキュリティ10大脅威2022個人編が出た
https://www.ipa.go.jp/files/000096258.pdf
情報セキュリティ10大脅威2022
2021年において社会的に影響が大きかったセキュリティ上の脅威について「10大脅威選考会」の投票結果に基づき順位付けがされています。
個人向けと組織向けの脅威は以下のようになっていました。
個人向けの脅威
- フィッシングによる個人情報等の詐欺
- ネット上の誹謗・中小・デマ
- メールやSMS等を使った脅迫・詐欺の手口による金銭要求
- クレジットカード情報の不正利用
- スマホ決済の不正利用
- 偽警告によるインターネット詐欺
- 不正アプリによるスマートフォン利用者への被害
- インターネット上のサービスからの個人情報窃取
- インターネットバンキングの不正利用
- インターネット上のサービスへの不正ログイン
組織向け脅威
- ランサムウェアによる被害
- 標的型攻撃による機密情報の窃取
- サプライチェーンの弱点を悪用した攻撃
- テレワーク等のニューノーマルな働き方を狙った攻撃
- 内部不正による情報漏洩
- 脆弱性対策情報の公開に伴う悪用増加
- 修正プログラムの公開前を狙う攻撃(ゼロデイ攻撃)
- ビジネスメール詐欺による金銭被害
- 予期せぬIT基盤の障害に伴う業務停止
- 不注意による情報漏洩等の被害
SNS上で話題になった(少なくとも自分が目にした)脅威
「2021年 脅威の名称」で検索すると話題になったニュースが見つかります。
ワクチン接種の予約システム脆弱性とゼロデイ攻撃
ワクチン接種の予約システムが架空の予約番号で予約できる脆弱性が判明し、対策がされる前にSNSやマスコミでそのことが拡散されてしまった。
その結果、興味本位で予約する人も現れ、本物と偽物の予約の区別がつかなくなった。といったところでしょうか？
ゼロデイ攻撃をするのはもちろんNGですが、ゼロデイ攻撃につながるような情報発信も危険だと思ったことを覚えています。
部品工場がランサムウェアの攻撃を受け、トヨタが国内全工場停止
これは2022年3月1日の出来事ですが、組織向けの脅威1位のランサムウェアの内容だったため取り上げます。
「日本のトップ企業のトヨタの工場停止に成功した。それなら日本の他の企業にランサムウェアの攻撃しても有効だろう」みたいな考えになっている気がするので、今後もランサムウェアの被害が増えていきそう。
ランサムウェアとは
- Ransom(身代金)とSoftware(ソフトウェア)を組み合わせて作られた造語
- ランサムウェアはマルウェアの一種(悪意のあるソフトウェア)
- 端末を利用できないように暗号化し、身代金を要求する(身代金を払っても復号してくれない気がする)
とはいえ、ランサムウェアで攻撃すると企業に反撃される時代になったようです。(日本にも、このような企業があると心強いのですが)
情報セキュリティ対策の基本
ソフトウェアの脆弱性
ソフトウェアの更新：脆弱性を解消し攻撃によるリスクを低減する
ウイルス感染
セキュリティソフトの利用：攻撃をブロックする
パスワード窃取
パスワードの管理の・認証の強化：パスワード窃取によるリスクを低減する
設定不備
設定の見直し：誤った設定を攻撃に利用されないようにする
誘導(罠にはめる)
脅威・手口を知る：手口から重要視するべき対策を理解する
内部不正による情報漏洩などの考察
内部不正による情報漏洩について考えます。(参考：R2秋 応用情報)
- 保有する情報は管理規定に基づいて、秘密区分を設定
- 電子文書や書類に、区分に沿ったマークを表示または押印して誰でも判別できるようにする
- そのシステムの利用者だけに業務上必要となる最低限の機能を利用できる権限(アクセス権)を付与する
- システムが保有する情報をPCや許可された可搬型記憶媒体にダウンロードできる
- 資産価値または重要度の高い情報の社外へ持ち出しは原則禁止されているが、持ち出す場合は、管理者の承認を得た後に持ち出すことができる
内部不正に対する技術面での対策(あくまで応用情報の話)
USBメモリなどの可搬型記憶媒体の運用が、管理規定どおり行われていない。
対応：PCの操作ログの取得機能やデバイス制御機能を持つPC管理システムを導入する。
デバイス制御機能では、許可されていない可搬型記憶媒体のPCへの接続を拒否することで情報の不正持ち出し抑制する方法
メールや社外のWebサイトの利用が、管理の規定通り行われていない
対応：
- 添付ファイル付きのメールに対して、あらかじめ指定された上司に通知し、上司の承認後に送信する
- プロキシサーバでURLフィルタリングを稼働させ、業務上必要なWebサイトをホワイトリストに登録してアクセスを許可し、それ以外のWebサイトは遮断する
ホワイトリストに含まれないWebサイトの中に、業務上必要となるサイトが存在する場合、利用したいWebサイトの認定申請をする。
重要情報へのアクセス履歴および利用者の操作履歴などのログの取得と管理が適切に行われていない
対応：
プロキシサーバとPC管理システムですべてのログを取得するとともに、新たにメールアーカイブ機能を有効にする
プロキシサーバのログでは、通信が行われた日時・作業者のID・アクセス先IPアドレス・操作内容などができるようになる
※作業者のIDを特定できるようにするために、プロキシサーバでは利用者認証を実施する。
PC管理システムのログでは、送信されたメール本文・ファイルの内容・送信者および宛先が特定できるようになる
ディジタルフォレンジックス
不正アクセスや情報漏えいなどのセキュリティインシデントが発生した際に、インシデントに関係するコンピュータやデバイスなどの機器から、原因究明や法的証拠に必要となる電子的記録を収集し、保全し、解析すること
内部不正の対策案を社内に告知する
実施するセキュリティ対策を告知することは、社内の意識向上だけでなく、内部不正を抑止力となります。
情報を不正に社外に持ち出すのが難しいことや不正を隠し通せないと分かるためです。
組織における内部不正防止ガイドライン
p67からの付録が充実している
https://www.ipa.go.jp/files/000057060.pdf
内部不正防止のための基本原則
- 犯行を難しくする(やりにくくする)
対策を強化することで犯罪行為を難しくする - 捕まるリスクを高める(やると見つかる)
管理や監視を強化することで捕まるリスクを高める - 犯行の見返りを減らす(割に合わない)
標的を隠したり、排除したり、利益を得にくくすることで犯行を防ぐ - 犯行の誘因を減らす(その気にさせない)
犯罪を行う気持ちにさせないことで犯行を抑止する - 犯罪の弁明をさせない(言い訳させない)
犯行者による自らの行為の正当化理由を排除する
標的型サイバー攻撃対策などの考察
標的型サイバー攻撃について考えます。(参考：R1秋 応用情報)
情報セキュリティ10大脅威の1つとして毎年あげられています。
不審なメールの添付ファイルを実行したときの対応
マルウェアの感染が判明した（または感染が疑われる）ときは、社内のネットワークから被疑PCを切り離すべきです
具体的には、まず次のことをしてください。
- パソコンのLANケーブルを抜く
- 無線LANのスイッチを切る
社内の他の機器と通信させないためです。
これにより、次のことを防ぐことができます。
- ネットワークを介して感染を広める
- 攻撃のために通信する
その後、セキュリティ担当者に報告します。
不審なメールに気づいたときにとるべき行動は
不審なメールに気が付いたときには、自組織のインシデント対応部署やセキュリティ担当に報告し、指示を仰ぐのが適切な対応です。
- 返信しない
- 添付ファイルの開封しない
- URLリンクを開かない
ファイアウォールのログを分析する
マルウェアに感染したPCがインターネット上の特定のサーバとの通信を試した場合、FWのログに通信の履歴が残ります。
標的型サイバー攻撃対策(あくまで応用情報の話)
FWによる遮断
- PCからインターネットへのアクセスに対して許可する通信を決める
PCへのマルウェア対策ソフトの導入
メールサーバにおけるメール受信対策
- メールサーバ向けマルウェア対策ソフトを導入して、届いたメールの本文や添付ファイルのチェックを行い、不審なメールを隔離する。
- SPF(Sender Policy Framework)などの送信ドメイン認証を導入する
送信ドメイン認証は、送信元メールアドレスのなりすましを検知することができる。
メールサーバにおけるメール送信対策
- PCからメールを送信する際にも、利用者認証を行う
利用者認証を行うことで、標的型サイバー攻撃の目的が情報窃取の場合、メール経由で情報が外部に漏洩する恐れを低減できる。
インターネットアクセス対策
- PCから直接インターネットにアクセスすることを禁止(FWで遮断)し、DMZに新たに設置するプロキシサーバ経由でアクセスさせる
- プロキシサーバでは、利用者IDとパスワードによる利用者認証を導入する
- プロキシサーバでは、不正サイトや改ざんなどで侵害されたサイトを遮断する機能を含むURLフィルタリング機能を導入する
水飲み場攻撃によって、マルウェアをダウンロードさせられることがある。
これは標的ユーザが良く利用するWebサイトにドライブバイダウンロードのコードなどを仕込み、アクセスした標的ユーザにマルウェアやウイルスを感染させる攻撃です。
URLフィルタリング機能を用いることで被害を軽減できる。
ログ監視対策
- ログ監視サービスを利用して、FWやプロキシサーバのログ監視を行い、不審な通信を検知する
C&CサーバがURLフィルタリング機能でアクセスが遮断されないサイトに設置された場合、プロキシサーバの利用者認証情報を窃取する機能を備えていると回避されることがある。
マルウェアとは何か
マリシャスソフトウェア(悪意のあるソフトウェア)で略してマルウェアです。
ユーザーのデバイスに不利益をもたらす悪意のあるプログラムやソフトウェアを指す。
マルウェアの種類
ウイルス
自己増殖する
宿主が必要
ワーム
自己増殖する
単独で活動
トロイの木馬
自己増殖しない
偽装して活動
スパイウェア
偽装して活動
マルウェアの感染経路
ホームページの閲覧
昔は怪しいWebサイトだけ避けていればよかったのですが、最近では正規のWebサイトが不正侵入を受け、書き換えられ、ウイルスが仕込まれるケースがあります。
その場合、正規のWebサイトを閲覧してもウイルスに感染してしまいます。
信頼できないサイトで配布されたプログラムのインストール
「あなたのコンピュータはウイルスに感染しています」のような不安をあおるメッセージを出して、利用者を偽のウイルス対策ソフトを配布するWebサイトに誘導します。
電子メールの添付ファイル
電子メールに添付されてきたファイルが悪意のあるプログラムだった場合、ウイルスに感染してしまいます。
USBメモリからの感染
USBメモリをコンピュータに差し込んだだけで自動的にプログラムが実行される仕組みが用意されています。これを悪用してコンピュータに感染するウイルスがあります。
会社のビルに見知らぬ人がいて「ここの社員の方がUSB落としましたよ」といって渡してきたUSBメモリがウイルスに感染するものだった！といった話を聞いたことがあります。
ファイル共有ソフトによる感染
別のファイルに偽装して、いつの間にかウイルスを実行させられてしまうことがあります。
電子メールのHTMLスクリプト
添付ファイルがなくても、HTML形式で書かれているメールの場合、ウイルスに感染する場合があります。
電子メールソフトの中には、HTMLメールのスクリプトを自動的に実行する設定になっているものもあり、電子メールをプレビューしただけでウイルスに感染します。
ネットワークのファイル共有
ウイルスの中には、感染したコンピュータに接続されているファイル共有ディスクを見つけ出し、特定のファイル形式など、ある条件で探し出したファイルに感染していくものです。
組織内のネットワークを通して、他のコンピュータやサーバにも侵入して感染を広げます。
マクロプログラムの実行
VBAを用いたマクロプログラムではファイルの書き換えや削除などができます。
VBAで記述されたウイルスが実行されて自己増殖などされます。
マルウェアで起こる被害
- 個人情報を抜き取られたり、情報が流出したりする
- デバイスに保存されているファイルが改ざんされる
- デバイスを勝手にロックされて持ち主でも操作ができなくなる
- 外部と勝手に通信を行う
- デバイスを乗っ取られ、サイバー攻撃の「踏み台」として使われる
マルウェアに感染しない予防方法
ECサイトの利用者認証の考察
インターネット通販用のWebサイト(以下、ECサイトという)で、不正アクセスを防止する対策を考えます。(参考：H31春 応用情報)
3種類の利用者認証
- 利用者の記憶、知識をもとにしたもの
例：ID・パスワード - 利用者の所有物をもとにしたもの
例：ICカード・ディジタル証明証・ワンタイムパスワード・マトリックス認証・SMS認証 - 利用者の生体の特徴をもとにしたもの
例：指紋・虹彩・筆跡・顔・網膜・静脈パターン(経年による変化が少ないもの)
安全性と利用しやすさの面を考える
セキュリティ対策がされたECサイトでも、使い勝手(利用者と運営者)が悪ければ意味がないです。
そこで、先ほど紹介した3種の利用者認証の安全性と利用しやすさを考えてみます。
- 記憶、知識：安全性△, 利用しやすさ〇
- 所有物：安全性〇, 利用しやすさ△
- 生体：安全性〇, 利用しやすさ△
2と3は、利用者に認証デバイスまたは認証情報を配布する必要があるため、ECサイトの利用者認証には向いていない場合があります。
ID・パスワード認証のリスク
ID・パスワード認証を狙った攻撃手法が存在している。
- ブルートフォース攻撃
IDを固定して、パスワードに可能性のあるすべての文字を組み合わせてログインを試す - 逆ブルートフォース攻撃
パスワードを固定して、IDに可能性のあるすべての文字を組み合わせてログインを試す - 類推攻撃
利用者の個人情報などからパスワードを類推してログインを試す - 辞書攻撃
辞書や人名録などに載っている単語や、それらの組み合わせた文字列でログインを試す - パスワードリスト攻撃
セキュリティ強度の低いWebサイトまたはECサイトからIDとパスワードが記録されたファイルを窃取し、解読したID・パスワードのリストを作成しリストを用いて他のサイトへログインを試す
1~4への対策は、パスワードとして設定する文字列を工夫することが重要。
5への対策は、認証情報の管理方法を工夫することが重要。
パスワードの入力試行回数の上限値を設定することで、1の攻撃への対策はできるが2の攻撃からは有効ではない。
また、他のWebサイトやECサイトから流出した認証情報が悪用された場合、対処できない。
(興味本位で不必要にサイトへ登録するのは止めましょう。そのサイトのセキュリティ対策が甘いと危ないので)
パスワードをハッシュ化してパスワードが知られることを防ぐ
パスワードをハッシュ関数によりハッシュ化し、平文のパスワードの代わりにハッシュ値を秘密認証情報のDBに登録する。
ハッシュ化の特性
- 入力データが同じであれば、常に同じメッセージダイジェストが生成される。
- 入力データが少しでも異なっていれば、生成されるメッセージダイジェストは大きく異なったものになる。
- メッセージダイジェストから元の入力データを再現することが困難である。
- 異なる入力データから同じメッセージダイジェストが生成される可能性が非常に低い。
ハッシュ値からパスワードの割り出しは難しく、万が一DBから情報が流出しても、平文のパスワードを知られてしまうことを防止します。
(暗号化はもとに戻すことを前提にしているが、ハッシュ化はもとに戻すことを前提にしていないため、ハッシュ化する前のパスワードを割り出すことが技術的に難しい)
ハッシュ化でも防げないレインボー攻撃
- 攻撃者が、膨大な数のパスワード候補とそのハッシュ値の対応テーブル(Rテーブル)をあらかじめ作成(または入手)する
- 窃取したアカウント情報中のパスワードのハッシュ値をキーとして、Rテーブルを検索する。一致したハッシュ値があれば、パスワードが割り出される。
レインボー攻撃はオフラインで行われ、時間や検索回数の制約がないため、パスワードが割り出される可能性が高い。
レインボー攻撃の対策としてパスワードにソルトを結合する
- 会員が設定したパスワードのバイト列に、ソルトと呼ばれる十分な長さのバイト列を結合する(ソルトは会員ごとに異なるものとする)
- ソルトを結合した全体のバイト列をハッシュ化する
- ID、ハッシュ値、ソルトを秘密認証情報のDBに登録する
ソルトを使った対策により、Rテーブルの作成が難しくなるため、パスワードの割り出しがしにくくなる。
会員に求めるパスワードのルール
- 会員自身の個人情報をもとにしたパスワードを設定しないこと
- 辞書や人名録に載っている単語をもとにしたパスワードを設定しないこと
- 会員が他サイトで利用しているパスワードを使いまわさないこと
1,2は推測されやすいパスワードになるためNGです。総務省のサイトに安全なパスワードと危険なパスワードの例が載っているため参考にしてください。
3はセキュリティ強度が低い他サイトから流出したパスワードによって，不正ログインされる場合があります。
具体的にいうと、流出したパスワードを使ってパスワードリスト攻撃して不正ログインされるリスクがあります。
参考：
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_1/2019h31h_ap_pm_qs.pdf
