|
現在実施している活動に関して郵送物を受領できない方に向けてITチームが追いかけている事象・対象に関してご説明いたします
尚、チーム全体では実際に現地に赴き、ご近所等への聞き込みを実施している「調査チーム」も存在します。それら総合的な情報に基づいて今回の活動は構成されております。
我々ITチームは以下の構成要素に対する調査やデータ保全依頼、クライアントベースで可能な証跡保管活動を行っています
� 敞�信元端末】 設置ルーターから付与されたIPアドレスを使用
（プライベートIPアドレス）
�◆攘戚鵐襦璽拭次曄ゞ疥戮鯊�ねているアクセスポイントのDHCPサーバーからのIPアドレスを使用
（一般的にこれが監視システム上で表示されるIPアドレスとなる）
ここまでが家庭・事業所内
携帯電話の場合は上記構成は若干変わります
��【ISP DHCPサーバー】 多段の場合もあるがこのゾーンよりグローバルIPアドレスを使用
（原則としてWHOISサーバーに登録されており、誰でも検索が可能）
ここのサーバーに「いつどの契約ルーターにどのIPアドレスを付与した か？」の記録が存在する。
�ぁ撻優奪肇錙璽�ディスパッチャ】 Webサービスを提供している各社は負荷分散をするため実際のアプリケーションサーバーは複数稼動させている。
それらを効率良く稼動させるため、通常利用者がアクセスしている先は実体サーバーではなく「振り分けサーバー」であるネットワークディスパッチャにアクセスしている。その際にアクセス要求してきたIPアドレスからのパケットを混乱無く配分するために「セッションID」を付与する。この時のログとして「いつの時点でどのIPアドレスにどのセッションIDを付与したか」の対応表がDB上に作成される。
�ァ撻▲廛螢院璽轡腑鵐機璽弌次曄．屮蹈暗�のサービス実体を構成している。実際には「アプリケーションサーバー」「データベースサーバー」の２つで構成されており
利用者が記入する文字列やアップロードした画像等はデータベースサーバーに保管されている。画面の遷移、構成、データのCRUD（生成・参照・更新・削除の頭文字）コントロール（すなわちSQL文）等はアプリケーションサーバーが担当する。全てのデータはテーブル上のレコードとして管理されている。
�ァ檻院攤鐔�方式】障害発生時の復旧対策として各レコードは「物理削除」ではなく「論理削除」を採用、「削除フラグが立っているものは表示しない」という方式で「見かけ上、消えているように」見せている。この方式を採用することにより「消えたデータ」を復旧させる事（≒ロールバック）が可能となっている。
�ァ檻押�SQLログ】また「SQLログ」というものも管理しており、どのセッションIDがデータベースにどんな要求を指示したかを記録している。
たとえばあるブログにて「こんにちは」とコメントした場合には
（SQL命令部分）＋「こんにちは」＋「投入先ブログ記事ファイル名」＋「コメントファイル名」＋「セッションID」
のように記録される。
（注：実際の文法等はもっと複雑なので表記上では抽象化しております）
�ァ檻魁�DBスナップショット】ある時点でのデータ状態を丸ごと複写する機能として「スナップショット」を利用できるようになっている。基本的には手動操作となるので運用部門による臨時オペレーション（通称「臨オペ」）となる。特定の範囲だけをスナップショットすることも可能。テスト環境や再現環境に移植すれば当時の画面状態を再現できる。
【解説】
一連の動きはすべて「セッションID」によって紐づいています
ここで言う「ID」とは利用者がサービス先に登録しているものではありません
機械的に「見えないところで自動的に付与」されているものです
ログインしていようがログオフであろうが関係ありません
また、別のIDでログインしていても関係ありません
複数ログインしていても同一セッションIDになります
「SQLログ」をExportしてセッションIDでソートをかければ
「あるセッションIDにて行った事全て」の表が出来上がります
そしてネットワークディスパッチャの振り分けログで
「その時間帯にどのIPアドレスにセッションIDを付与したか？」
が判明します
次に��を管理しているISPのログを参照し
「その時間帯にどのルーター（＝契約者：個人名）にIPアドレスを付与したか？」
を確定させます
以上の照合作業を行う事により
「だれがどれだけ悪さをしていたか？」
が確定します
先日ISP各社との協議でこれらの情報を保管しておくことには合意がなされております
（2年以上前から問題発生した時期を選んで保管していただいています）
（2008年分以降に関してはさらにDBスナップショットを追加でお願いしております）
ポイントはあくまで「保管」までで
公式な「照合作業」等は提訴時となります
ただし「公益通報制度」を採用する場合にはISP各社から自発的に検察への告発という形で照合結果が提出されます
ここのハードルは「悪質度」ということになり
「どれだけの長期間、多くの人達に対して迷惑行為を行ったか？」
「実際にブログ等の閉鎖に追い込まれたか？」
「当事者間での協議を困難とするような隠蔽が行われているか？」
等の積み上げが必要になります
非公式にどの程度の規模なら？と伺ってみたところ
「一年以上、10名以上に対して、2つ以上のサイト閉鎖」
との非公式回答を頂戴してます
ここでの単位は個人単位ですので複数IDによる行為は一つに束ねて考えます
我々の依頼者だけでも充分可能な規模ですが、補完するためにも
賛同していただける方々を近日中にブログ上にて公募する予定です
また、訴追対象者を支えている者の抽出も同時に実施しております
技術的なアドバイス、積極的な擁護等、結果責任を問えると判断できる相手は
同様に対象とします
我々の方ではここで判明する
「（当事者＋支援者の）契約者」
を告発する相手とします
実体としては利用者と契約者は異なるかもしれません
しかしながら、実際の使用者が自ら申し出ない限り
「法的な手続き上で立証される相手」
は
「契約者」
になります
場合によっては相手先の家庭なり法人なりを崩壊させる事になりかねない訳で
依頼者様の中にもご家庭をお持ちな方もいらっしゃり
その辺をご心配されてます
この理由から
「即訴訟に持ち込まず、当人からの積極的な謝罪」
を期待していたわけです
正式には近日開催の全体会議にて決定されますが
果たしてそれまでに本人からの真摯な対応がでるか・・・・
会議の行方はそこにかかっているように思えます
|
