2015年4月30日木曜日

【情報セキュリティ】 オリンピック開催にあわせて新設される無料Wi-Fiについて思うこと

こんにちは。

最近家庭用プラネタリウムを買って、部屋中に広がる星を見ながら涙を流している鷲尾です。


さて、先日発表されたApple Watchですが、みなさんはもう買いましたか?
一部では充電後が熱くて腕にまけない!なんて声もありましたが、あったらあったで便利なのではないかと思います。(私は買っていませんが・・・)

こういったウェアラブル端末も普通のスマホもそうですが、通常はWi-Fi接続されていることが前提です。買ったはいいけどオフラインでしか使いませんという人は、なかなかいないですよね。

みなさんご存知の通り、2020年には東京オリンピックが開催されます。
そこで政府は今、オリンピックに合わせて、無料のWi-Fiを整備しようとしています。
これに関しては様々な意見がありますが、今回はこのオリンピックに合わせて増える無料Wi-Fiに関して、書いていきたいと思います。


■そもそもなぜ増やすのか

2020年、オリンピック開催に合わせて、たくさんの外国人観光客が日本に押し寄せてくることが予想できます。一部では、外国人観光客が2000万人とまで言われています。
現在の日本の人口の約6分の1が日本に入ってくるわけです。それも関東に集中して、です。
今でも相当な量のトラフィックが発生している東京で、さらに数千万人規模の外国人がWi-Fi接続をした場合、今までどおり高速にインターネットは使えると思いますか?

答えはNOです。トラフィック(通信量)がいっぱいいっぱいになるのも、想像に難くありません。



2015年4月23日木曜日

Fusion Tables×Google Apps Script (マッピング編2) ~Google Analyticsのデータをインプットに、Fusion Tablesでマッピングする~

こんにちは、井下です。

少し間が空いてしまいましたが、今回の内容は前回予告していた通り、Google Analytics・Fusion Tables・Google Apps Scriptの3つを組み合せ、Google AnalyticsのデータをFusion Tablesに持ってきて、マッピングをできるようにしてみます。

なお、次回からはFusion Tables以外の話を書くつもりです。
気が付けばFusion Tables関連で6回もやっていました。ゴールをどこにしようか迷っていたとかじゃありませんよ。

ちなみに今まで書いた内容はこちら


実装したい内容の手動実行
実装を行う前に、具体的にどんなことを行おうとしているのかを、手動で実演してみます。
実装内容だけ知りたいという方は、ページ下部まで進んでください。

今回、実現したいことは、「Google Analyticsのデータを都道府県別に色分けできる状態にしたマップを作成する」ことの自動化です。

それを手動で行おうとすると、次のような手順を踏むことになります。
  1. Google Analyticsから地域別のデータをFusion Tablesに移行する
  2. 移行したデータの入ったテーブルと、都道府県名+都道府県の領域の情報が入ったテーブルをマージする
なお、"都道府県名+都道府県の領域の情報が入ったテーブル"に関しては、前回のブログに書いてありますので、詳細についてはそちらご参照ください。


まず、Google Analyticsから地域別のデータを表示します。
なお、例として利用しているデータは"国"に"Japan"を指定しているので、都道府県別のデータが表示されています。


Google Analyticsのエクスポート機能を使ってFusion Tablesへ移行したいのですが、Google Analyticsから直接Fusion Tablesへはエクスポートできません。
代替手段として、一度スプレッドシートへエクスポートし、Fusion Tablesからスプレッドシートのデータをインポートします。

なお、Google Analyticsは表示されている1ページ分のデータしかエクスポートしてくれないので、表示行数を調整して、欲しいデータが入るようにしておきましょう。



スプレッドシートへのエクスポートを選択すると、確認画面が開きます。問題がなければ"はい。データをインポートします"を選択します。


エクスポートに成功したので、作成されたスプレッドシートを確認してみます。


次はスプレッドシートのデータをFusion Tablesにインポートします。
Fusion Tablesの新規作成から"Google Spreadsheets"を選択し、先ほど作成したスプレッドシートをインポート対象にします。


スプレッドシートからインポートする場合、何行目をカラムとして見なすかを選択します。


スプレッドシートでは6行目にカラム名が記入されていたので、"6"を選択しました。


テーブル名などを新規作成前に設定できますが、特に変更せずに"Finish"を選択します。


これでようやくGoogle Analyticsから、Fusion Tablesへデータを移行することができました。


ただし、前回説明したように、この状態では都道府県ごとのマッピングはできません。都道府県ごとの境界がどこからどこなのかを、レコードごとに与えなければなりません。

都道府県ごとの境界のデータを持つテーブルは前回作成していますが、境界のデータを1レコードずつ入力するのは非常に手間がかかるので、できれば避けたいところです。

そこでFusion Tablesのマージ機能を利用します。
Fusion Tablesのマージ機能を一般的なDBで言うなら、"結合ビューの作成"と言えるでしょうか。

今回はGoogle Analyticsからエクスポートしたテーブルをベースに、都道府県の境界データを持ったテーブルをマージしてみます。

マージ機能を使うには、"File"メニューの中段下あたりにある"Merge"を選択します。


マージする対象のテーブルを選択する画面が開くので、都道府県の境界データを持った"Japan"テーブルを選択します。(前回作成していたテーブルで、デフォルトで用意されているわけではないので注意)


テーブルを選択すると、2つのテーブルから、それぞれカラムを選択する画面が開きます。
ここで選択したカラム同士で、合致するデータがあるレコードのみ表示するビューを作成することになります。


それぞれ都道府県名が入ったカラムを選択してみましたが、ここで1つ問題が発生しました。
Google Analyticsからエクスポートしたテーブルでは、都道府県名の後ろに"Prefecture"が付いていることがありますが、もう片方のテーブルではそういった文字列は付いていません。

このままではカラム同士のデータ合致判定が思った通りに機能してくれません。


仕方がないので、どちらかのデータを修正します。
手早く修正するために、Google Analyticsからエクスポートしたスプレッドシートの" Prefecture"を一斉置換で削除し、新しくテーブルを作成することにします。
(Fusion Tablesだと1つずつしかレコードを修正できず、SQLの発行もGoogle Apps Scriptなど外部実装を介さなくてはできないので、少し時間がかかります)



データを修正したテーブルで改めてマージをしてみます。互いに都道府県名の入ったカラムを選択します。


次にどのカラムを表示するのかを選択します。Google Analyticsのカラムはとりあえず全て表示させておきますが、もう片方のテーブルで欲しいカラムは、都道府県の境界データを持ったカラムだけなので、それ以外のカラムのチェックを外します。


これでMergeを選択すると、設定した条件のビューが作成されます。


Google Analyticsからエクスポートしたテーブルをベースとして、都道府県の境界データの入ったカラムが追加されています。(一番右のカラム)


このビューのマップ表示をしてみると、まだ数値ごとの色分けこそされていませんが、都道府県が赤で塗られています。(赤で塗られていないところは、データが存在しないことを示しています)
ここまで来れば、後はどのカラムを色分けの基準にするか、どんな値ごとに色分けするかを設定するだけです。




ここまでかなり長くなりましたが、やりたいことのイメージとしては、Google Analyticsのデータをインプットとして、日本地図に色が塗られているテーブルを、ひと月ごとに自動作成してくれる実装です。



実装による自動化
手動で行った手順を元に実装していきます。ただし、手動とは違ってわざわざスプレッドシートに一度エクスポートする必要はありません。また、手動で修正していた都道府県名の" Prefecture"の削除も内部処理で一括して行います。

2015年4月17日金曜日

AWS EC2インスタンス起動・停止自動化によるコストの最適化【自動化編】

こんにちは、井下です。
本日は、集中連載企画の第3回目【自動化編】となります。


前回のあらすじ
● ステータス確認、起動・停止、Elastic IPの関連付けといったAPIを実際に実行してみる
● インスタンスの起動・停止バッチを作成し、そのバッチで実際にインスタンスを起動・停止してみる
※ 過去のブログはこちらをご参照ください。
  第1回 準備編



今回は集中連載企画の最終回ということで、いよいよA-AUTO 50でインスタンスの起動・停止のスケジュール、実行を自動化し、最適化を図ります。


今回のAgendaは次のとおりです
  9.カレンダーの作成
 9.1 年間定休日を定義する
 9.2 カレンダーを作成する
10.スケジュール情報の登録
11.ジョブネットワーク情報の登録
12.ネットワークスケジュールの作成
13.バッチファイルの配置
14.インスタンスの起動・停止の監視


では、さっそく説明に入っていきますが、以降の説明は、既に基本ライセンスのインストール手順に従って、インストールが完了している前提で話を進めます。
このため、予めインストール手順に従ってインストールを完了させておいてください。

・ Webクライアントにログインできる状態にある
・ 監視ウィンドウのテンプレートを作成済みで監視画面が表示できる状態にある
・ 動作確認まで完了している



9.カレンダーの作成
はじめに、お客様独自の営業日カレンダーを作成します。

先ずは、カレンダー作成を考えるにあたり、いつが休みかを決めていきます。
一般的な休みの種類は、大きく以下の3つに分類できると思います。

(a) 週間定休日 : 毎週土曜日や毎週日曜日といったように毎週繰り返しやってくる休日
(b) 年間定休日 : 国民の祝日など毎年繰り返しやってくる休日
(c) 不特定の休日 : 会社固有の休日
             例えば、夏季休暇や年末年始休暇、GWを大型連休にするために
             休みを振り替えたりすることがあると思います。
             ※ 年末年始休暇などは、企業によっては毎年期間が同一だったりもしますね


次にA-AUTOのカレンダーを作成するうえでの休日の種類は次のようになります。

(ア) 週間定休日 : 毎週土曜日や毎週日曜日といったように毎週繰り返しやってくる休日
(イ) 年間定休日 : 毎年n月n日と言うように日付が固定され毎年やってくる休日
            元旦(1月1日)、建国記念日(2月11日)などがこれに相当します
            また、年末年始休暇が毎年12月29日~1月4日と固定されているようであれば、
            これも年間定休日として考えます
(ウ) 不特定の休日 : ハッピーマンデーや春分の日、秋分の日といった毎年日付が変わる国民の休日や、
            夏季休暇、GWの連休設定など、月日で固定化できない休日がこれに該当します

先ずは、一般的な休みの種類とA-AUTOの休日の種類で若干異なる部分があることが分かっていただけたかと思います。
※ 現時点でA-AUTOでは、”毎年n月のn週目のn曜日”といったハッピーマンデーには未対応としているため、不特定の休日に分類します




9.1 年間定休日を定義する
先ずは、A-AUTOの休日の考え方のうち(イ)の年間定休日を登録します。
年間定休日は、マスタメンテナンスメニュー[ホリデー]-[休日]を選んで表示される[休日定義一覧]から登録します。

A-AUTO 50をインストールした状態では、日付固定の国民の休日は予め登録してあります。
このほかに会社固有の年間定休日があれば、はここで登録してください。

  ※ 旧 日付固定の国民の休日も登録されているので、不要でしたら削除してください



会社固有の年間定休日は、[新規登録]ボタンをクリックして登録します。

”日付”フィールドで月日を入力または選択してください。
下記のサンプル画像は、「1月2日」を登録しています。”コメント”フィールドに「年末年始休暇」など後から見て分かるようなコメントを入れておくとよいです。


なお、[振り替え]チェックボックスがありますが、指定した日付がカレンダー上休日の日曜日であった場合、休日を翌日に自動振り替えするか否かを選択するためのものです。
※ 上記サンプル画像では、会社固有の休日であるため[振り替え]の設定は行っていません

下の画像は、同様に「1月3日、1月4日、12月29日~12月31日」も休日として定義した後の画像となります。



※ [振り替え]を行う設定をしている休日は、一覧表示をしたときに、日付の右横にアイコンが表示されます


9.2 カレンダーを作成する
お客様固有のカレンダーを作成します。
カレンダーは、マスタメンテナンスメニュー[ホリデー]を選んで表示される[ホリデー定義一覧]から登録します。

2015年4月15日水曜日

AWS EC2インスタンス起動・停止自動化によるコストの最適化【API利用編】

みなさんこんにちは。
鷲尾です。

本日は、短期集中連載企画の第2回目【API利用編】となります。


前回までのあらすじ

● ローカル環境に Amazon EC2 API Toolsを導入
● インスタンスの操作に必要となる情報を収集し、環境変数を設定するバッチファイルを作成
● 作成したバッチファイルとec2ver”コマンドでAmazon EC2 API Toolsが利用できることを確認

今回は「API利用編」ということで、インスタンスのステータスの確認、インスタンスの起動・停止が行えることを確認し、最終的に起動・停止用のバッチファイルの作成・実行まで行っていきます。

※なお、コマンドは各環境変数に値がセットされていないと実行することが出来ないため、ここでは、前回作成した環境変数設定バッチ(envSetup.bat)を実行した状態(環境変数に値がセットされている状態)であることを前提としています。

6.インスタンスのステータス確認
先ずは、ターゲットとするインスタンスIDの操作が行えることを確認するために、特定インスタンスのステータスを取得します。

ステータスを確認する場合は、以下のコマンドを使用します。
ec2-describe-instances インスタンスID


コマンドを投入したときの表示は以下のような表示となります。
■起動時



ここまでくれば、もうAPIでの起動・停止ができたも同然です!



7.インスタンスのStartStop
次は、いよいよインスタンスの起動・停止を制御してみます。
それでは、停止状態にあるインスタンスを再起動(Start)させてみましょう。

再起動させる場合は、以下のコマンドを使用します。
ec2-start-instances インスタンスID                                                                    


startコマンド投入サンプル

      ※ i-XXXXXXXXには、実在するインスタンスIDを指定してください


今度は、起動しているインスタンスを停止(Stop)させてみます。
停止させる場合は、以下のコマンドを使用します。

 
ec2-stop-instances インスタンスID       

stopコマンド投入サンプル


これで、APIからインスタンスの起動・停止が行えるようになりました!


なお、起動・停止用のAPIは、非同期処理となっています。このため、ec2-start-instances /ec2-stop-instances から処理が戻された時点で、指定したインスタンスの起動・停止は完了していません。
このため、ec2-start-instancesec2-stop-instancesを利用した場合、正しく起動・停止したかは、前述のec2-describe-instancesコマンドなどを利用して確認する必要があります。






8.Elastic IPアドレスの関連付け(EC2 Classicの場合のみ)
EC2(Classic)では、インスタンスを停止するとその時点で、インスタンスとElastic IPの関連付けが解除されてしまいます。
このため、停止・起動の自動化を行う場合、インスタンス再起動後に再度Elastic IPの関連付けを行う必要があります。
Elastic IPの関連付けには、以下のコマンドを使用します。
ec2-associate-address -i インスタンスID Elastic IP

Amzon EC2 VPCの場合は、インスタンスを停止してもElastic IPアドレスは開放されません。




9.起動・停止用バッチファイルを作成・実行してみる
インスタンスを起動・停止するためのバッチファイルを作成します。
ここでは、起動および停止バッチをインスタンス毎に作成しないよう、1つのバッチファイルを共用する前提でバッチファイルのパラメータを定義します。

【起動バッチ : ec2start.bat】

起動バッチのサンプルはこちらからダウンロード出来ます。
作成するバッチの概要は以下のとおりです。
パラメータ
1つのバッチファイルで複数のEC2インスタンスを起動するバッチとするため、パラメータを3つ用意します。
1パラメータ : リージョンコード (必須)
2パラメータ : インスタンスID  (必須)
3パラメータ : Elastic IP     (任意)

EC2 Classic環境で、Elastic IPアドレスの関連付けをする前提としているため第3パラメータを用意していますが、EC2 VPCであれば停止後にインスタンスとElastic IPアドレスとの関連付けが解除されないので第3パラメータは不要です。

◆リターンコード
  0 : インスタンスの起動に成功した
  1 : 起動しようとしたインスタンスIDが既に起動しているため、処理を中止した
  4  必須パラメータが入力されてない
  8  インスタンスへの接続に失敗した
12  Elastic IPアドレスの関連付けに失敗した(起動バッチのみ)
16 :インスタンスの起動に失敗 した

第3回の自動化編では、リターンコードが0、もしくは1であれば正常とみなすように設定します。

2015年4月13日月曜日

AWS EC2インスタンス起動・停止自動化によるコストの最適化【準備編】

みなさんこんにちは。

今年の新人のフレッシュな声を背中で聞きながら、しみじみ過去の1年間を回想している鷲尾です。


さて、みなさん「AWS」はご存知ですよね。

AWSを利用すると、アマゾンが提供する環境に「Linux」や「Windows」といったさまざまなOSを「インスタンス」という形で、仮想的に利用することができます。
例えば「AWS上にCentOSなどのサーバ向けOSのインスタンスを用意し、そのサーバ上でWebサイトを運営する」といった使い方ができます。

非常に便利なAWSですが、気になるサービス利用料は「使った分だけの従量課金」となっています。つまり、「インスタンスを起動している間は料金がチャージされ、停止している間は料金は掛からない」というわけです。


であれば、少しでもインスタンスの起動時間は短くしたい(コストを抑えたい)ですよね。
しかし、毎日手動でインスタンスを起ちあげては停止し、また起ちあげて・・・ということを繰り返すのは大変ですし、オペレーションミスが発生するかもしれません。

また、「会社の営業日だけ起動させたい」、「営業時間の間だけ」、「今週は起動したくない」といったインスタンス操作のタイミングが不規則で複雑な場合、すべて手動で管理するのはさらに大変です。


そこで、強力なスケジューリング機能をもった無料の「A-AUTO 50」とAmazon EC2 API Tools」を連携させてインスタンスの起動・停止をすべて自動化し、インスタンス起動日時をより細かくコントロールすることでコストを削減してしまいましょう!というのが今回のテーマです。

『cronやタスクスケジューラでできるでしょ!』と思われる方もいらっしゃると思いますが、連載を読み終えていただければ違いがわかっていただけると思います。


AWSとA-AUTO 50連携イメージ




すべてを1回で書ききるにはボリュームがあるので、全3回の短期連載とします。

第1回:準備編
第2回:API利用編
第3回:自動化編


 
なお、本連載で使用する環境は、弊社内のWindows Server 2008R2環境からAWS上のRed Hatのインスタンスの起動・停止を行います。
使用するOSAMI)は以下のとおりです。

・接続元(社内ローカル環境)
Windows Server 2008R2

・接続先(AWS上)
Red Hat Enterprise Linux 7.1 (HVM)ami-4dbf9e7d


※AMIというのは、インスタンスの元になったOSイメージのことです。例えばRedHatのインスタンスを作成するときはRed HatのAMIからコピーして作成します。




ということで、ここから第1回の「準備編」の内容に入っていきます。

準備編

インスタンスの起動・停止を制御するためには、インスタンスをAPIで操作するためのコマンドラインツールAmazon EC2 API Tools」、インスタンスを起動・停止するそれぞれのバッチファイルと、その他AWS関連の登録情報が必要です。

※注意
本投稿での「起動」という用語についてですが、便宜上“停止状態にある既に生成済みのインスタンスを再開(Startさせること”を「起動」と記載させていただきます。
なお、正式なAWSの用語は以下のとおりです

 ・ インスタンスの起動(run         AMIから新しいインスタンスを生成・起動する
 ・ インスタンスの停止(stop       起動中のインスタンスを停止する
 ・ インスタンスの再開(start)        停止中のイスタンスを再び起動する
 ・ インスタンスの削除(terminate インスタンスの起動で生成したインスタンスを削除する


ということで、第1回目の目標は、「Amazon EC2 API Tools 」を利用できるようにする所までです。


それでは以下の順に説明していきます。

1. Amazon EC2 API Toolsとは
2. Amazon EC2 API Toolsのダウンロード
3. Amazon EC2 API Toolsのインストール
4. Amazon EC2 API Toolsを使用するための準備
-  4.1 事前に準備しておく情報一覧

-  4.2 設定する環境変数の設定
5. Amazon EC2 API Toolsの動作確認

2015年4月2日木曜日

【情報セキュリティ】電子署名とタイムスタンプで防止する4つの脅威

こんにちは。

満開の桜に心を癒やされている気がする鷲尾です。

今週から4月にかけて、桜のラッシュだそうです。
ぜひ土日には桜を見に行きたいですね。


さて、今回は前回の続き、電子署名についてです。
前回の内容はこちら

前回は、「もし公開鍵証明書が発行されていなかったら」といった場合を例に、公開鍵証明書の信頼性や必要性を紹介しました。

今回は電子署名ということで、電子署名とはどういったものなのか、電子署名によって何が出来るのかについて書きたいと思います。


■電子署名とは
前回も触れましたが、電子署名とデジタル署名の違いは、みなさんご存知でしょうか。デジタル署名?電子署名を英語で言っただけじゃないの?とお思いの方もいらっしゃるかもしれません。

電子署名とは、インターネット上で商取引を行う際に通信相手が本人であること、また通信内容が改ざんされていないことなどを電子的に証明するものです。早い話が現実世界での「ハンコを押す」、「サインをする」といったものと同じです。そういった行為の仕組み、その電子版が電子署名というわけです。この電子署名という仕組みを実現する最も有力な方法が、公開鍵暗号方式を使った「デジタル署名」なんです。このデジタル署名にも実は数種類ありまして、例として使用する公開鍵暗号方式の方式ごとに、

・RSA方式
・DSA方式
・ECDSA方式

などがあります。


■電子署名とタイムスタンプ
電子署名の仕組みは、様々な技術を組み合わせて実現されています。現実社会で一般的に「証拠」といわれるものを論じる際、多くは「いつ、だれが、なにを、どこで」だと思います。
「どこで」というのは物理的な場所だとして、この中で電子署名でカバーできるのは、実は「だれが、なにを」だけなんです。「いつ」というものは電子署名だけでは証明出来ないのです。そこで利用されているのが「タイムスタンプ」というものです。


■タイムスタンプ
タイムスタンプは、文字通り「時刻をスタンプ」し、「いつ、なにを」を証明するものです。作成された文書に「この日この時刻に、確かにこの文書は存在した:否認※」というものを証明することが出来ます。さらに、「この時刻以降、この文書は改ざんされていない:完全性」ということを証明することも出来ます。

タイムスタンプは、信頼できる第三者機関を通して「ハッシュ」という技術を使って、文書に付与されます。タイムスタンプを付与された文書は、電子署名によって「だれが、なにを」を証明し、さらに「いつ」も証明できるうえ、「否認」を防ぐことができるので、多くの場面で利用されています。

          

※参考:IPA 情処理推進機構 https://www.ipa.go.jp/files/000013707.pdf


■電子署名でできること
電子署名では、大きく以下の4つのことを防止することが出来ます。

1.なりすまし
有名なものはフィッシング詐欺などです。本物そっくりにつくられたHPなどで重要な情報を入力していますことにより、第三者に情報を知られてしまいます。しかし、こういったフィッシングサイトに飛んでしまう理由として、偽物のメールに記載してあるURLをクリックし、フィッシングサイトに飛んでしまうことが多いのです。そういった時に、偽物のメールに電子署名がされているのか、またその内容が正しいのかを確認することで、事前になりすましメールから身を守る事ができます。

2.改ざん
メールなどの内容が途中で書き換えられてしまうことです。例えば「料金は1,000円です」というメールを途中で書き換え、「料金は1,000,000円です」などとすることを言います。こういった場合は、メールに付与されている電子署名を確認します。電子署名を付与したメールには「ハッシュ値」という値が予め付与されており、文書の内容が変更されるとその値も変更されます。したがって、改ざん前のハッシュ値と比較して差異があった場合、途中で改ざんされたと判断できます。

3.否認
否認というのは、電子商取引等で、操作を行ったあとになって「やってないよ!」」と「操作したことを否認すること」です。これがなかなか厄介で、例えば株取引をしているとき、自分の操作によって大損をしたとします。もちろん、操作をなかったことになんて出来ません。しかしここで、自分が操作したにもかかわらず「そんな操作はしていない。だから株取引も無効だ」と、操作したことを認めない行為をする人がいます。これが否認です。

4.盗聴
ネット上での通信内容を、第三者が覗き見ることです。文書をやりとりする際に全く暗号化などをしていない場合、簡単に中身を覗き見ることが出来てしまいます。
しかし、電子署名を行っておくことで、第三者に覗き見られても、内容を見られることはありません。電子署名では、送り主が送る際に暗号化し、受け取り主が受け取った後に復号するためです。暗号化された文書を第三者が傍受したとしても、復号できず中身を見られることはありません。


電子署名という技術は、私達が安全にインターネットを利用するうえで無くてはならない存在です。
さらに今は当たり前のように誰もが電子商取引をします。もしネットバンキングのログインページが偽物だったら、もし重要な会社の資料を悪意のある第三者に見られてしまったら・・・

「電子商取引」というとなんだかビジネスマンや、専門家が行っているようなイメージを持つかもしれませんが、普段楽天やAmazonなどで買い物をするのも立派な電子商取引なんです。
自分はきっと大丈夫という慢心をせず、そういった危険もあるのだということを忘れないでほしいと思います。


- ちなみに -
特に否認に関しては、少し前に話題になったPC遠隔操作事件などでも、「私はやっていない」と言いはっていてなかなか決着がつきませんでしたよね。現在のIT系の犯罪は、実は紙媒体での証拠取り押さえというのは非常に少ないんだそうです。スマホに残っていた操作ログや、様々な機器を経由した時の通信ログ、GPSのログなどを調査し、証拠として扱われているようです。
常に持ち歩いているスマホには、様々な種類のデータが膨大に存在します。
こういったスマホの中に眠る電子的な証拠=デジタル・フォレンジックというものについてもどこかの機会で触れたいと思います。