エージェントの配布漏れで特定部署の端末のログが収集されない
新設部署への配布漏れや版の不一致があると、対象端末の操作ログが記録されないまま運用が続き、監査や調査の局面で欠落が判明します。
GENZ, Inc.
ログ管理の検証
ログ管理ツールの
ログ管理の検証
ログ管理ツールの収集から通報までを第三者が検証
収集・保管・検索・通報の連なりを一連の業務シナリオとして検証し、どこまでを範囲としたかを記録として残します。リリース判断と監査対応に使える形でご提供します。
支援事例
支援実績5,000件以上
ログ管理ツールでよくある不具合
ログ管理ツールの不具合は、設定ミスや転送上の障害が起きても画面上は正常に見えるため、疎通確認だけでは見落とされます。収集・保管・検索・通報の各段で起きうる代表的な欠落の形を、判明する局面とあわせて整理します。
エージェントの
転送経路の障害や保管領域の上限到達で、特定期間のログが欠落する
転送経路の障害や保管領域の上限到達が起きると、特定期間のログが保存されません。障害の復旧後も、失われた期間の記録は再取得できません。
正規化定義の誤りで項目値が別の項目に格納され、検索条件に一致しない
複数機器から取り込むログの正規化定義に誤りがあると、項目の値が別の項目へ格納され、記録が存在するのに検索条件に一致せず結果に現れません。
保管期間が規程と合わず証跡が自動削除される
自動削除の保管期間が社内規程の保管年数と一致していないと、提出が必要な期間の証跡が削除されます。削除後のログは復元できず、監査で示せません。
通報のしきい値設定が実態と合わず、誤検知の多発と検知漏れが混在する
しきい値が実態と合わないと、誤検知の多発と検知漏れが混在します。一次確認の負荷が上がる一方で、本来検知すべき事象を見逃すおそれがあります。
残存した不具合により生じる問題
検証の範囲を決められないままリリースした場合、残存した不具合は導入後の調査・費用・監査の局面で表面化します。
静的テスト（レビュー）でおさえるべき観点
設定を入力する前に、定義書や規程と突き合わせておくべき観点があります。ここで見落とした不整合は、リリース後の検索欠落や監査指摘として表面化します。以下に挙げる照合が、レビューの起点です。
取得範囲の定義漏れがあるままリリースすると、監査で要求された対象のログが最初から取得されておらず、再取得不能な期間の証跡を提出できません。
取得範囲定義と社内規程の要求項目を照合する
社内規程や監査要求が定める取得範囲と、取得範囲定義書の項目を照合します。パソコン操作・Web・メール・印刷・サーバー・クラウドサービスのどれを取るかは目的で異なり、漏れを一覧で確かめます。
確認する資料
- 取得範囲定義書
- 社内規程
- 監査要求一覧
保管期間の設定が規程より短い場合、監査対象の期間のログがすでに削除されており、取得範囲の設計から遡る是正と再取得不能期間の説明が必要になります。
保管期間・改ざん防止の設定値と規程で定めた保管年数を照合する
保管期間の設定値が、規程で求める保管年数と一致しているかを照合します。自動削除の期間設定が規程より短い場合、満了とともに特定期間のログが失われ、監査時に証跡を提出できなくなるおそれがあります。
確認する資料
- 保管設定一覧
- 保管規程
- 削除設定画面
正規化定義の誤りを見逃すと、ログは収集されていても検索で該当の記録が出てこない状態が続き、利用部門からの照会が情シスへ繰り返し持ち込まれます。
正規化定義と各送出元のログ出力仕様を項目単位で照合する
複数の機器・サービスから異なる形式のログを取り込む構成では、正規化の定義が各送出元の出力仕様と合っているかを項目単位で照合します。定義の誤りは、検索しても記録が出てこない形で表面化します。
確認する資料
- 正規化定義書
- 送出元仕様書
- 項目対応表
配布グループの不整合があると、対象端末の一部にエージェントが導入されないまま運用が続き、端末単位の取得欠落が重大事象の調査の局面で判明します。
配布グループ定義と組織図・権限設計を照合する
エージェントの配布グループ定義と、組織図・権限設計を照合します。組織変更や端末の増減が手作業での対応となる構成では、配布漏れや版の不一致が長期間表面化しないまま取得の欠落につながります。
確認する資料
- 配布グループ定義
- 組織図
- 権限設計書
通報条件と運用体制の不整合を放置すると、誤検知の多発で確認が追いつかなくなるか、検知漏れで重大な兆候を見逃すかのいずれかの状態に陥ります。
通報条件と運用体制の対応可能件数・対応手順を照合する
通報条件のしきい値と、運用側が対応できる件数・手順を照合します。しきい値が運用体制に合わない場合、誤検知の多発か検知漏れのいずれかに偏り、通報が実務で機能しない状態が続きます。
確認する資料
- 通報条件定義
- 対応手順書
- 運用体制表
- 誤検知記録
動的テストの設計・実行のポイント
疎通の確認だけでは、ログの取得の正しさは担保できません。検証範囲をテストの工程ごとに分けて設計し、段階を追って実施します。
STEP 01
ユニットテスト取得種別ごとに出力項目と境界値を確かめる
どう確かめるか
ユニットテストで、取得種別ごとの出力項目と境界値を確かめる
パソコン操作やWeb閲覧、メール、印刷の取得種別ごとに、出力項目と境界値の期待値を定義し、出力と突き合わせます。疎通の確認では拾えない項目の欠落や値の誤りを、この段階で検出します。
- 01取得種別ごとに出力項目と期待値を一覧で定義する
- 02境界値を入力し、期待どおりの出力になるかを検証する
- 03項目の欠落や値の誤りを不具合票として記録する
OUTPUT出力項目と期待値の定義
STEP 02
統合テスト収集から保管・検索までの連携を確かめる
どう確かめるか
統合テストで、収集から正規化・保管・検索までの連携を確かめる
エージェントや各機器から収集したログが、正規化と保管を経て検索で取り出せる状態にあるかを確かめます。形式の異なるログでは、正規化の定義の誤りが検索結果の欠落として表面化します。
- 01収集から正規化、保管、検索までの経路を洗い出す
- 02形式の異なるログの正規化の定義が正しいかを検証する
- 03複数の機器のログを時系列で突き合わせられるかを確認する
OUTPUT連携経路の検証結果の記録
STEP 03
システムテスト監査・調査の業務シナリオと異常系を確かめる
どう確かめるか
システムテストで、監査・調査の業務シナリオと異常系のテスト観点を確かめる
監査や内部調査で特定期間・特定端末の証跡を提出する業務シナリオを、通しで検証します。転送経路の障害や保管領域の上限到達といった異常系のテスト観点で、欠落の起きる条件を確かめます。
- 01監査・調査で求められる証跡提出の業務シナリオを定義する
- 02特定期間・特定端末のログを条件どおりに取り出せるかを検証する
- 03転送の失敗や保管領域の上限到達を意図的に発生させて検証する
OUTPUT業務シナリオの検証結果
STEP 04
回帰テスト更新や更改の前後で挙動差を確かめる
どう確かめるか
回帰テストで、版の更新・基盤更改の前後の挙動差を確かめる
エージェントの版の更新や基盤更改の前後で、収集・保管・検索の挙動に差がないことを確かめます。仕様変更を伴わない更新でも挙動が変わるおそれがあるため、変更ごとに範囲を定めて実施します。
- 01更新・更改の内容から回帰テストの対象範囲を決める
- 02適用前の収集結果と検索結果を基準として記録する
- 03適用後に同じ条件で検証し、挙動の差を確認する
OUTPUT更新前後の挙動比較の結果
GENZが代行するログ管理ツールのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 取得・保管・検索・通報の期待値を定義したテスト項目書が残ります
- 検証範囲を明記した記録で管掌部長のリリース判断に提出できます
- 設定の写しではない検証の実施記録として監査に証跡を示せます
- 更新時の回帰テスト範囲を定型化し毎回同じ基準で確かめられます
検証範囲を第三者の視点で設計する
検証範囲を発注側とベンダーの二者だけで決めると、受け入れ時の確認と監査への説明が同じ記録で足りません。GENZは第三者の視点で、取得・保管・検索・通報のどこまでを検証範囲とするかを文書に起こします。
設計書からテスト設計を起こす
設計書と収集設定の定義から、取得範囲・保管期間・通報条件ごとに確かめる項目をテスト項目書の形に整理します。
収集から通報までを検証範囲に
収集の設定確認で終わらせず、保管・検索・通報まで一連の業務シナリオとして検証し、連なりの途中での欠落を表面化させます。
どちらの体制でも検証の役割を組み込みます
発注側にQA配置がある場合もベンダー側で進める場合も、既存の体制に合わせてスプリントと並行しながら検証の役割を組み込みます。
監査にもリリース判断にも使える報告書
何をどこまで検証したかを範囲として明記した報告書を提出し、管掌部長のリリース判断と監査での証跡提示の双方に使える形で残します。
ご相談から納品までの流れ
取得対象や監査要求が固まっていない段階からご相談いただけます。以下の流れで報告書の納品まで進みます。
ヒアリング｜取得対象と既存体制を確認
取得範囲・保管期間・通報条件の現行設定と、監査側からの要求を確認します。
テスト設計と見積もりのご提示
確認した範囲からテスト観点と検証項目を設計し、見積もりをご提示します。
実施と共有｜テスト実行と不具合の共有
設定の正しさを実環境で検証し、検出した不具合を随時ご共有します。
報告書の納品と是正後の再テスト
結果をまとめた報告書を納品します。是正後は再テストで修正を確認します。
受け入れ・リリース判断の前に
ログ管理ツールの検証範囲と優先順位を、GENZにご相談ください
どこまでを検証範囲とするか、どの順で確かめるか。相談の場でテスト範囲と優先順位、必要な工数の考え方、関連テストの要否まで整理し、管掌部長や監査担当へ示せる形でお渡しします。