「IT」カテゴリーアーカイブ

2014-07
09
11:23:02
AWS EC2のダイナミックIPを起動時に自動的にRoute 53へ登録してスタティックに利用できるようにしてみる

技術ネタ, , , , ,

AWS EC2を使っている人なら重々承知しているように、EC2サーバーは再起動する度にパブリックIP(とプライベートIPも)は動的に割り振られるので毎回異なったIPが振られることになります。
これ、他のVPSに慣れていると割と面倒臭く、まあIP資源は有限なので有効に使うには仕方ないのも理解できるし、本当に固定したいならElastic IPを設定すればいいのだけど、何台も管理しているといろいろ面倒臭くなりますよね。

なんかつい最近NO-IPとかの外部Dynamic DNSサービスを使って固定したDNS名で扱えるようにする方法が紹介されていたような気がするのだけど、最近NO-IPがマルウェアの温床だとしてマイクロソフトが裁判所にドメイン差し止めを申し立てたなんて嫌なニュースがあったり、どうせなら自分のドメイン使いたいよねとか、そもそもAWSなんだからRoute 53で管理したいよね、と思うので、実は僕はEC2起動時にシェルスクリプトを実行してRoute 53へAWS API経由でNameタグをホスト名としてその時のIPアドレスを登録して、ダイナミックDNSのように(厳密にはプロトコルは違う)使用しています。
つまりNameタグとしてホスト名を設定できて(本当は別タグにしてもいいです)、SSHとかでずっと同じDNS名で指定できるようになります。
割と便利に気軽に使えるようになって満足しているので、本稿でちょっと紹介してみます。皆さんのご参考になれば嬉しいです。

と言いつつ実は元々はネット検索していろいろなチャレンジされているのを幾つか参考にして組み合わせつつ自分でも試行錯誤して作ったんですが、どれがどれだったかURLとか忘れてしまっているので、ここであらためて参考にさせて頂いた方々へ感謝申し上げたいと思います。直接ご紹介できなくて申し訳ないです。

Continue reading →

2013-12
10
00:23:28
SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか

技術ネタ, , ,

以下のTogetterでまとめて頂いているが、大垣靖男氏と「何故氏はSQLインジェクション対策においてプリペアドステートメントの利用よりも入力データのエスケープ処理を優先するのか」について議論させて頂いた。

SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論

僕の疑問は一番最初の方にもあるが、「プリペアドステートメント+プレースホルダーで複雑な自作エスケープなどせずともシンプルにさほどの技術力も無く少なくとも『SQLインジェクション対策』としては機能するのに、何故そこまでエスケープ処理対応を一義に拘るのか」という点だった。

この優先順位度合いは以下のブログの部分からも明らかだ。

出力先のシステムが同じでも、出力先が異なる、を意識する

実際の開発に利用するコーディングルールでは出力先によって「API ＞ エスケープ ＞ バリデーション」の順番になる場合もありますが、セキュリティを維持するための重要度は「エスケープ ＞ API ＞ バリデーション」であることは変わりません。

さて経緯は上記Togetterに譲るが、結論として何故氏はそのような無謀な主張を延々繰り返すか、氷解したような気がする。
少しツイートもしたが誤解があるかも知れないのでもう少し詳しく説明しておきたい。またこれは以外に面白い視点も内包しているかも知れない。

Continue reading →

2013-09
04
06:44:48
ワンタイムパスワードの送付先にケータイメールは相応しくない

IT, 技術ネタ, , , ,

近年大手のWEBサービスも含めて所謂リスト攻撃などで不正ログインが多発するなどしており、一躍注目を集めているのが二要素認証(二段階認証)だ。通常のユーザーID/パスワードでの認証に加えて、その一時にだけ有効なワンタイムパスワード(OTP/One Time Password)を発行しこれも一致しないとログインを認めない方法である。
このワンタイムパスワードの発行方法またはユーザーへの送付方法には幾つかのパターンがある。
最も「厳しい」物理的なハードウェアトークンをユーザー毎に配布して表示される番号をワンタイムパスワードとして入力する方法(Paypalでの例)や、より簡易にスマホなどのソフトウェアでワンタイムパスワードを確認できる方法(有名なソフトウェアとしてはGoogle Authenticatorなどがある。但しサービスがこれらのソフトへ対応していないといけない)のほか、もっとも一般的には「ユーザーが別途指定したメールアドレスへワンタイムパスワードをメールする」方法がある。

ワンタイムパスワード自体は二要素認証のためだけの方法でも無い。ログイン時だけでは無く、例えば銀行サイトで他口座への振込などの資金移動をする際にワンタイムパスワードの設定をしていなければ操作できなくしている銀行も多い。これもまた近年高まっているセキュリティ保護の機運を反映したものだろう。

最近ではスマホなどモバイル環境の一般化によってか、「メールアドレスへのワンタイムパスワードの送付」パターンの場合にはPC用メールアドレスでは無く「ケータイメール」(すなわち携帯キャリアが提供しているメール)への送信を強く要請してくるようになった。
例えば三菱東京UFJ銀行や楽天銀行では最近になって「携帯メールでの登録」を勧める旨の記載が増えた。

三菱東京UFJ銀行 / インターネットバンキングのログイン時の本人確認方法を一部追加します。（平成24年2月12日（日）より）

楽天銀行 / セキュリティ強化のためのワンタイム認証のルール変更について

一方以下はGoogleでの二要素認証設定時の様子だ。ワンタイムパスワードの取得方法としてGoogle Authenticatorを使用することも出来るが、デフォルトではこのように各携帯キャリアのメールアドレスを指定することになっており、設定後は信頼できない端末からのログインの際はこのアドレスへワンタイムパスワードが送られる。

スクリーンショット 2013-08-02 5.19.49

前述の通り幾つかのバリエーションはあるものの、これらの例のように近年ではワンタイムパスワードは「ケータイメール」へ送付することが大変一般的になってきたと感じるし、実際多くの方がそのようにされているのでは無いだろうか。

しかしながらPCメールなどよりも「ケータイメール」をワンタイムパスワードの入手元とすることは果たして「より安全」な方法だろうか。

Continue reading →

2013-08
08
07:16:23
#Suica履歴提供 問題は何を問題にしなければならないか

IT, 時事ネタ, , , , ,

#Suica履歴提供 問題はまだまだ一旦落着したわけでは無くて、JR 東日本と日立側にまだ問題解決を突きつけているし、また従来から暗に言われていたにも関わらず本当に「自分のプライバシーが自分の知らないところで売られることがある」点を明瞭にしたという意味では「素晴らしい」スタディケースであるというべきだろう。また現在進行中の総務省 「パーソナルデータの利用・流通に関する研究会」においても「想定外の」こうした具体的インシデントを得ることでより踏み込んだ議論や検討にも役立つことになるだろう。

一方で我々利用者である。果たして今回の問題で「何が悪かったのか」「何を問題としなければいけないのか」明瞭に理解し主張できる人も少ないかも知れない。
端的には「何だか気持ち悪い」「自分の知らないところで勝手なことをするな」でよいのだ。難しい議論は専門家に任せて我々は「庶民感覚で」JR東日本など庶民感覚にかけ離れた企業マインドを叩いて構わないのである。
しかしと同時に少しだけ今回の一連のことが「論理的には」どういう意味を持つことだったのか知ることもまた決して損では無いだろう。

Continue reading →

2013-07
30
12:58:24
#Suica履歴提供 モバイルSuicaで機種変などしてSuicaIDが変わってしまうと販売データから除外依頼できなくなる場合がある

IT, 時事ネタ, , ,

意外に広まっていないので注意喚起のつもりで記載しておく。

JR東日本が先日以降日立にSuicaの乗車履歴データを販売すると発覚したことで大騒ぎになった。当初JR東日本からの発表が一切無かったことが混乱に拍車をかけていたが、その後騒ぎについて謝罪しある程度の情報開示をし、希望者はSuicaIDをJR東日本へ連絡することで販売分から除外することを明らかにした。
そのあたりの経緯については以下の記事に詳しい。

Suica乗降履歴データの外部提供で問われるプライバシー問題—JR東日本に聞く
販売されるデータは

  • SuicaID番号から他の形式に変換した識別番号。期間は明らかにされていないが定期的に変更されるとしている。
  • 乗降駅
  • 利用日時
  • 利用額
  • 生年月(当初生年月日との報道もあったが日は含まれない模様)
  • 性別

また鉄道利用履歴のみで物販は含まれないという。

JR東日本では、そもそものプライバシーポリシーでは「個人情報は第三者へは提供しない」としているが、SuicaIDから個人を特定できない番号に変換しているので既に個人情報には該当せず販売には問題無いとしている。
しかしこれまでまさか自身の利用履歴が外部に販売されるなどとは露ほどにも思わず利用してきた利用者からすれば何とも納得のいかない経緯であり、また「気持ち悪い」と感じる人も多いことだろう。

JR東日本では今回の問題に関するQ&A(PDF)を発表し、その中で7/26よりSuicaIDを連絡すれば販売データから除外する受け付けを開始する(つまりオプトアウト)と発表している。
メールでは jogaiyobo@jreast.co.jp へどんな内容でも良いので、モバイルSuicaならメイン画面、Suicaカードなら裏面にあるJEから始まる番号を送信すれば良い。正常に受け付けられれば受付メールが返信されてくる。
また電話 03-5334-1655 でもオペレータが受け付けているが平日10時から17時までの受付なので普通のサラリーマンでは使いにくいかも知れない。

さて問題は自分の履歴を販売データから除外したい場合に通知する必要のある「SuicaID」である。勿論現在使用中のモバイルSuicaやSuicaカードの番号を伝えれば良いのだが、実はこのSuicaIDは「モバイルSuicaの機種変やビューカードの有効期限切れまたは再発行のタイミングで変更されてしまう」のである。

Continue reading →