エラー画面に現れない障害の原因
エラー画面は、ある時点でサービスを利用できなかったことを示せます。しかし、プログラムによる攻撃、機器の故障、設定ミス、通常の需要増加のどれが原因だったかまでは分かりません。障害の発生期間、平常時のアクセス、当日のシステム変更、技術担当者の分析を時系列で並べると、異常の原因についての推論を検討できます。
サーバー、ネットワーク防御サービス、CDNでは、記録される時刻や内容が異なる場合があります。書き出す際にタイムゾーン、記録の出所、保存期間も残すと、同じ一群の要求が実際にサーバーへ届いていたかを照合できます。目立つ画面の画像だけを抜き出すと、障害の前後にある原因の説明に必要な情報が欠けるおそれがあります。
普段よりアクセスが多いと述べる場合、その普段が同じ時間帯、同じ販売促進条件なのか、別の運用段階なのかによって、比較の意味が変わります。新サービスの開始や宣伝も利用状況を変えるため、基準を選んだ方法も数値とともに残します。指摘する側に都合のよい時間だけを切り出すと、原因の評価を誤るおそれがあります。
技術報告が攻撃の疑いと述べたり、別の原因を残したりしている場合、確定した攻撃と読み替えないことも必要です。運用担当者の取引への影響の観察と、技術担当者のログ分析は、情報の出所が違います。それぞれの観察と推論の範囲を分ければ、暫定的な判断を実行者の身元の証明と混同せずに済みます。
パスワードの取得は必須の前提ではない
第358条の侵入と第360条の干渉は、要件が異なります。第360条は、先に認証情報を盗んだり、パスワードを破ったりすることを要求していません。管理画面に入っていないという説明だけでは、電磁的方法による干渉を否定できません。ただし、具体的な方法、対象設備、正当な理由の有無は別に証明する必要があります。
適法な負荷試験については、委託の内容、対象、実施時間、許容負荷、停止条件を確認します。一度試験の許可を得ていても、別のサイトや期間、許可範囲を超えた操作まで認められているとは限りません。逆に、契約どおりの試験で予定した負荷が生じた場合、負荷の数値だけを見て、正当な理由のない攻撃と決めることもできません。
売上の減少額をそのまま損害にしない
この条文は、実際に損害が生じたことを要件とします。注文できなかった、サービスが止まった、復旧費用がかかったという主張には、影響を受けた時間と取引・業務の内容を示し、技術的な障害との関係を説明する必要があります。売上が減るかもしれないという予測と、既に起きた注文取消しや復旧支出は、証明すべき内容が違います。
障害前後の注文、返金理由、サービスの稼働状況、対応に要した作業時間を分けて保存する方法が考えられます。一日分の売上差をすべて攻撃による損害とする前に、販売促進の終了や決済サービスの障害など、別の原因も比較します。技術記録と業務資料が対応して初めて、どの影響が問題の干渉に結び付くかを説明しやすくなります。
送信元IPから先の確認も必要になる
要求の送信元は追跡の手掛かりですが、中継サービス、他人に制御された端末、共用ネットワークなどが使われると、IPアドレスと実行者の間に別の証拠が必要になります。同じ形式の要求が大量に記録されていても、それだけで誰が計画し、事情を知り、操作を支配していたかまでは判断できません。
元のログと書き出した複製を保存し、取得方法も記録すると、後の検討に使えます。推測した氏名を元の記録へ書き込むべきではありません。遮断や復旧の対応内容も、その後のアクセスを変えるため、残しておく意味があります。証拠のために障害を放置する必要があるということではなく、復旧の過程を後から確認できる形で残すという考え方です。
告訴と特殊なシステムの規定
刑法第363条により、第360条は告訴を要します。刑事訴訟法第237条では、告訴権者が犯人を知った時から6か月以内に告訴します。障害を知った時と犯人を知った時は必ずしも一致しません。一方、技術報告が完成していないから期間も始まらないと決めることはできません。
公務機関の設備には、第361条の刑を2分の1まで加重する規定があります。金融など特別なシステムでは、別の法律の対象や要件も個別に確認する必要があります。一般のウェブ障害についての資料だけで、それらの法律判断まで完結するわけではありません。事業者の規模が大きいという理由だけで、適用条件を確かめていない重い規定を当てはめることも避ける必要があります。
刑法第361條 · 刑法第363條 · 刑事訴訟法第237條