AWS Casual Talks#2 で発表してきた
開催からもう一週間経って今更感しかないのですが、 AWS Casual Talks#2 という勉強会で AWS CloudTrail の話をしてきました。
アレなタイトルですみませんでした。。。
CloudTrail の話と言いつつ、前半1/3くらいを Heartbleed ネタに使ってしまいましたが ちょうどホットな話題だったのと、AWS 周辺でこの話してる人あまりいないなあと思っていたので つい入れてしまいました。
30分もの枠で対外発表するのは初めてだったので正直かなり緊張していました。 終わってみると、喋り方や話のまとめ方など色々反省点が多いなあと思いつつ、楽しかったです。
CloudTrail についてもうちょっと
スライド中に、ログを取るために HTTP Proxy をかますことを考えた、みたいなことを書いてるのだけど、 そうするとその Proxy を通さないリクエストはロギングできなくなる、 つまり例えば IAM でリクエスト元 IP とかを Proxy のものに縛っていたとして、 リクエスト元 IP が違う (= Proxy 使ってない) リクエストは当然ロギングできないわけで、 やっぱり API に対してのログとは言えないなあと思っていました。
AWS の怖いところの一つとして、目に見えているもの以外の部分が見えにくいということを かなり感じていたので、ネタではなく CloudTrail さんには一日も早く太平洋を渡ってきてほしいなあと願っています。
iwas について
iwas という CloudTrail のログをパースして IAM の変更履歴を記録するものを作ってみました。
CloudTrail のログ通知を SNS 経由で SQS に吐くようにしてあげると使えます。
IAM の変更履歴って、権限変更の記録というセキュリティの面から見ても 個人的にはかなり必要なものだと思っていて、IAM に実装されないのかなーとずっと思っているのですが、 そういう気配がなかったので作りました。
ちなみにネーミングは IAM (I am) の変更履歴を取るので I was ... にしていて、 個人的にはこのネーミングだけで行ける！！！！！とか思っていたのですが、 なんというか、社会は厳しかったです。
同梱している iam-export.rb は IAM のポリシを json ファイルにエクスポートします。 当初は aws-sdk for ruby の current 版を使ってたのですが、IAM Role の扱いに対応していなくて、 開発は aws-sdk-core (v2) にシフトしているようだったので、まだ pre ではありますがこちらを使ってみました。
が、中身を見ればわかるように正直全くプロダクションクオリティではありません。。。 すでにいくつか考慮漏れを見つけているので、近いうちに直して環境構築方法とともにきちんと公開しようと思います。
さいごに
次は EC2/VPC 上のインスタンス運用でのセキュリティとか、そういう話をする機会があればと思います。 というか AWS 系の勉強会は数あれど、その中で運用におけるセキュリティとかに焦点を当てたものって あまりなさそうなので、今度やってみたいですね。
というわけで、主催してくださった @con_mame さん、 会場提供してくださった AWS さん、他の発表者の方々、聞いてくださった方々、ありがとうございました。
AWS Game Day Japan 2014 に参加した
JAWS DAYS 2014 の前日に開かれた、 Game Day Japan 2014 に参加してきました。 AWS Game Day Japan 2014 Spring (Tokyo) - JAWS DAYS 2014 | Doorkeeper
Game Day そのものの詳細はクラスメソッドさんの Blog 記事が詳しいと思います。 すごく大雑把に言うと AWS で構築したシステムを全力で攻撃して全力で修復するというものです。
過去にも行われたようですが僕は今回が初参加でした。 Game Day そのものに興味はあったので今年もやるという噂をききつけてエントリー。 全会場で50人いかなかったら中止って書いてあって、平日ということもあり開催されるのかなーとちょっと不安でしたが 無事開催されることになって嬉しかったです。
会場に着いて説明のち、早速チーム分け。 チームメイトは @moomindani さんと @nginks さん。 自己紹介しつつまずはコミュニケーションツールを作る。 Google Docs だけでなんとかなるかと思ったけどチャットが欲しかった(声でバレるから)ので Skype も併用することにしました。
構築と防御
まず最初は構築フェーズ。EC2 と SQS を使ったシステムを手順に沿って作っていきます。 去年と同じだったらしいんだけど、どうせ問題変わるだろうと思って何ら予習しなかったので 2回目でーすって人が手挙げてたりして冷や汗ものでした。 構築はチームのお二人に任せつつ、防御周りのことをしたり構築を手伝ったり。 やったことはこんな感じ
- CloudTrail を有効化してログを他アカウントの S3 バケットに投げるように
- SQS の Dead letter queue を有効化して変なキューは自動で流せるように
- piculet でセキュリティグループの状態をコードとして保持
- 自作の IAM エクスポートスクリプトで IAM の構造とかを保持 (今回は IAM のみ触れないのであまり意味はないけど、読みやすいように)
などなど。色々考えましたがすっと手が動かないなーという反省。。。
EC2 が実行するワーカーに OS コマンドインジェクションを見つけて (去年も全く同じだったらしいけど) パッチ当てようか迷ったのだけど、 コード読んでたのが終了3分前くらいで間に合いませんでした。。。 あと CloudTrail のログを他アカウントに出すのは反則かなーと思ったけど、実際有効なんじゃないかなーと思ってやってみました。 ほんとは loggly の free account から読めるようにしてたんだけど、インポートがなぜかうまくいってなかったので諦めることに。 ちまちま作っていた自作のパーサと JSONView でなんとかしていました。
攻撃・修復
どんな攻撃があったかは ijin さんの Blog にほとんど記載されてるのでそちらをご参照ください。
AWS Game Day Japan 2014春を開催してきた - @ijin
相手に渡すアカウントは IAM の操作のみができない Power User Template だけを入れたアカウントだったので、 事実上ほとんどなんでもできる状態。 リソース全消しなどではなくバレにくく修復しにくい攻撃が評価されるとのことで、 事前に考えていた攻撃としては S3 の Bucket Policy 周り、Auto Scaling, OS コマンドインジェクション、VPC のネットワーク機能あたりを 攻めようと考えていたのですが、
攻撃用アカウントをもらってざっと目を通すとまさかの VPC 使わない (EC2-Classic) 環境…………
これで考えてた攻撃をかなり潰されてヒーという感じでした。その発想はなかった。。。
修復はだいたいできたものの、AutoScaling の Scheduled Action に仕込まれた攻撃を修復しきれず。 CloudTrail は多くのチームが壊しにかかったようですが、うちのチームは S3 Bucket を外に出していたこともあり無傷。 これについては後述。 1チームが複数チームから攻撃されるというアクシデントなどもありつつも修復フェーズおわり。
結果発表
結果、ほとんどのサービスに加えて Management Console も壊した (表示を触りまくった？) チームが優勝。 うちは厳しいんじゃないかしらと思ってたけどなんと地方賞(仙台賞)をいただきました。 どこ攻撃されたかわからないような攻撃が多かったのが評価対象だったようです。やったー。
感想
限られた時間でシステム作って修復するというのはなかなか難しく、 改めて思ったのは"正しい状態を保持して比較し続ける"ことの重要性でした。 例えばコードにエクスポートしていたセキュリティグループへの攻撃は、変更把握も修復も一発でしたし。
CloudTrail は正直 SQS や AutoScaling 周りへの攻撃がメインだった今回、あまり威力を発揮する場面はなかったかなーという印象。 ただ、リージョンが US だったこともあり、CloudTrail 環境下で作業をしていくとこういうログが取れるのかーというものが 手に入ったのは大きいと思いました。 Management Console も実際は各操作で API を呼んでいるので、相手がどんな順番でシステムの概要を把握していったのかある程度想像できたり。
IAM の Power User template では IAM の変更のみが禁止されてますが、監査という点から考えると CloudTrail への変更も デフォルトで禁止してほしいところです。。。
また、ログの保存場所について自分の考えを確認できたのも良かったです。 CloudTrail しかり ELB しかり、AWS への操作のログが徐々に取得できるようになってきてますが、 確実なログ運用のためには全く違うアカウント管理下にあるバケットへの格納など、どうやっても手がとどかない場所に保持しておくのは 一つの運用として良いのかなーと思いました。
色々と勉強になりました。次回も参加したいです。 運営の皆様、チームメイトの皆様、参加された皆様、ありがとうございました。
仮想化方式(HVM と PV)についてまとめ
EC2 における仮想化方式や kernel の扱いにはいくつか種類があって、 カスタマイズ (パフォーマンスチューニングなど) をする上で必要になることがあります。 C3 インスタンスや I2 インスタンスの登場で、それらがより重要になってきた感があるので一度まとめてみます。 * この記事は基本的に Linux についてまとめています
大前提
世に出ている仮想化基盤はいくつかありますが EC2 に使われているのは Xen です。 ただし ハードウェアサポートの追加、インスタンスタイプに応じた各 VM リソースの割り当て方、 ネットワークの扱いなど、 Xen そのものに相当なカスタマイズが行われていることは想像に難くないと思います。 (とか言って API から上だけで実現されていたらそれはそれで面白いですね)
仮想化方式
PV (paravirtual)
EC2 ではサービス開始当初から PV (paravirtual, 準仮想化) 環境でインスタンスの提供を行っています。 paravirtual での起動方法は2種類提供されています。
AKI, ARI を使う方式
EC2 側であらかじめ用意された kernel (AKI) と initrd (ARI) を利用して起動し、 最後にルートデバイスとしてユーザが選択したボリュームをマウントします。 つまり、ルートデバイスの /boot に kernel が含まれていようと、利用される kernel は AKI のものになります。 この方式で起動する場合、ユーザ側で作成するルートデバイスに kernel 本体や initrd が不要になります。 つまり /boot が無くても起動に問題無いはずです。
PV-GRUB を使う方式
UPK (User Provided Kernel) などとも呼ばれています。EC2 では後発で提供されるようになりました。 EC2 における PV-GRUB についてはこのへん、 Xen における PV-GRUB についてはこのへんにドキュメントがあります。 PV-GRUB 用 AKI を指定しておくと、ユーザが指定したルートデバイス内に含まれる kernel を使って起動できるというものです。 PV-GRUB は、ユーザが提供したルートデバイス内に存在する grub.conf を読みに行き、その内容を使って起動します。 grub.conf のパスは固定しておく必要がありますし、kernel を置いておく必要があるので、/boot が必要になってきますが、 ルートデバイスに grub がインストールされている必要はありません。
PV, PV-GRUB ともに、ルートデバイス内に適切にファイルが配置されてさえいれば起動します。 なので AMI をゼロから作る際に、適当な AMI で起動して EBS をアタッチし、 ファイルを流し込めば起動できるようになるんですね。
HVM
クラスタインスタンスがリリースされた際に HVM (Hardware-assited VM) という方式がサポート(というか必須)されました。 その頃だとあまり馴染みのなかった HVM AMI ですが、先日 C3, M3, I2 インスタンスがリリースされた時にこの方式がサポート(もしくは必須)されるようになっており、 一般の利用者にも関係のあるものになってきています。
HVM の場合、起動シーケンスは物理マシンに OS をインストールした場合と何ら変わりません。 ルートデバイスにあるブートローダから、デバイス内に含まれる kernel を起動していきます。 つまり、ブート領域 (GPT or MBR) とブートローダ (grub など) が必要になります。 そのため、既存の PV AMI を HVM 環境で使うためには、ファイルを流した EBS に対して grub をインストールしないといけません。 (ちなみに grub-install は Xen の仮想デバイスに対応していないので grub コマンドからインストールする必要があります) ゼロから作るのであれば、がんばって EBS マウントしたりするより手元の VMware とかでサクッと作ってディスクイメージにした上で dd したほうが早いかもしれません。 事故には気をつけたいですね。
HVM は完全仮想化などと言われているので特にモジュールなど必要なさそうに見えますが、実際はそうではありません。 試しに C3 インスタンスや I2 インスタンスで HVM AMI を起動してみると、Xen のモジュールが色々ロードされていることに気づくと思います。 これは PV on HVM driver と言われているもので、HVM 環境下ではオーバーヘッドが発生しやすい I/O などを PV の時と同様にホスト OS 側のサポートを受けつつ処理できるようにするドライバです。 ドキュメントにもありますが、このドライバは kernel 2.6.36 でマージされて 2.6.37 で改善が入っていますので、新しい kernel を使えるならそれ以上のバージョンを使うと良いです。 RHEL6 (CentOS6) の kernel は 2.6.32 ですが、2.6.36 のドライバがバックポートされているため問題なく利用できるようです。
ハードウェアサポートの利用
HVM AMI を使う必要のあるインスタンスでハードウェアサポートを提供しているものがあります。 代表的なのは C3, I2 インスタンスの SR-IOV による 10G NIC サポート (実帯域が 10G というわけではない) だと思います。 オリジナルの AMI を使う場合、こういったハードウェアサポートを有効にするドライバなどを忘れずロードできるようにしましょう。
使い分けや注意事項
各インスタンスがどの方式をサポートしているかのマトリクスはこちら。 古いインスタンスタイプは PV しかサポートしていないので選択の余地はないとして、 新しい C3, M3 インスタンスは PV と HVM の両方をサポートしています。 (I2 インスタンスは HVM 必須です) 個人的には、 PV と遜色無いパフォーマンスが出るのであれば HVM が使えるインスタンスではもう PV AMI 使う理由は無いかなーと思っているのですが、 きちんと計測が必要ですね。 問題になってくるのは同一の AMI を PV, HVM で使いたい時でしょうか。メンテナンスしなきゃいけない AMI が倍になるので。
EC2 のドキュメントでもインスタンスに利用されている CPU やハードウェアサポートが明記されるなど、 インスタンスが稼働している環境そのものを意識することが増えてきました。 今後はどうなっていくのでしょう。EC2 でも使えるハードウェアが色々増えていくと楽しそうですね。
cloudpack night #7 に参加しました / EC2 における AES-NI の話
先日行われた cloudpack night #7 に参加しました。
http://www.zusaar.com/event/978005
主催された cloudpack の id:yoshidashingo さんのまとめはこちら。
http://d.hatena.ne.jp/yoshidashingo/20130826/1377527798
新卒入社5ヶ月目、社会人なりたてのぺーぺーではあるのですが、 僭越ながら若手 LT 枠で発表させていただきました。
EC2 環境における AES-NI の性能について紹介しました。
AES 暗号化するならインスタンスをよく見たほうが良いですよ、という話です。
LT の資料だとうまくまとまらない気がしたので記事という形でまとめておきます。
AES-NI とは
詳細はここで説明するよりググったほうが良いです。
一言で言うと AES 暗号の CPU サポートで、Intel CPU の Westmere (2010年前半) 世代から載るようになったのでそれなりに日が経ってはいます。
OpenSSL(たぶん 1.0.0e~) では既に利用できるようになっています。
EC2 における AES-NI
結論から言うと、EC2 においても AES-NI を利用することができますが、1点だけ落とし穴が存在します。
ヘビーに AWS を利用されている方には既知の問題かと思いますが、
同じインスタンスタイプにおいても割り当てられる CPU が違うことがあります。
(この詳細は con_mame さんのエントリに分かりやすくまとめてあります)
もちろん AWS 側でも世代間の差が少なくなるよう、CPU によってインスタンスへの割当時間調整をしていたりするとは思いますが、
ハードウェアサポートについては如何ともしがたいところでしょう。
同じインスタンスタイプのインスタンスで、AES-NI がサポートされているものとそうでないものがあります。
AES-NI の有無によるパフォーマンスの違い
というわけで、どのくらいのパフォーマンス差が存在するのか検証を行いました。
m2.2xlarge (13 ECU) のインスタンス2台、CentOS6 の環境で、
OpenSSL はディストリビューション標準のパッケージを利用しています。
※計算速度の比較にどうして m2.2xlarge? という声もありそうですが、諸事情です
2台のマシンにははそれぞれ knight, padawan という名前をつけておきます。
フェニックス一号にしようかと思ったのですがやめました。
CPU の確認
まず2台の CPU を確認します。/proc/cpuinfo から得られる情報のうち関係ありそうな部分を抜粋してみます。
knight
processor : 0 model name : Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz cpu MHz : 2399.998 flags : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm rep_good unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes avx hypervisor lahf_lm
padawan
processor : 0 model name : Intel(R) Xeon(R) CPU X5550 @ 2.67GHz cpu MHz : 2666.760 flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm rep_good unfair_spinlock pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm
上記のように knight の flags には aes の文字が見えますが padawan にはありません。
このため、padawan (X5550) では AES-NI がサポートされていないものと考えられます。
※ Intel の Web サイトからも探せるようになっています
OpenSSL での確認
次に OpenSSL 側での状態を確認します。
knight
$ openssl engine -c -t
(aesni) Intel AES-NI engine
[AES-128-ECB, AES-128-CBC, AES-128-CFB, AES-128-OFB, AES-192-ECB, AES-192-CBC, AES-192-CFB, AES-192-OFB, AES-256-ECB, AES-256-CBC, AES-256-CFB, AES-256-OFB]
[ available ]
padawan
$ openssl engine -c -t
(aesni) Intel AES-NI engine (no-aesni)
[ available ]
というわけで、AES-NI が搭載された knight 側でのみ aesni モジュールでサポートできる 暗号化モードが表示されています。 これで、knight が AES-NI を利用でき、padawan はそうではない、ということが分かります。
OpenSSL ベンチマークオプションでの計測
openssl には speed オプションという暗号化モードのスループットを計測できるオプションがあります。
これを knight, padawan でそれぞれ実行しました。
暗号化モードとして AES256 (CBC モード) を利用して計測し、
同時に、AES-NI の有無以外での差がないか調べるため 3DES のスループットも計測しました。
結果
下記グラフのような結果が出ました。
グラフに載せ忘れてしまったのですが、単位は kbytes/s です。
256 bytes の暗号化スループット値を抜粋していますが、どのサイズでも開きは大体同じでした。
AES-256-CBC では knight が padawan に約5倍以上の性能差をつけています。
逆に 3DES では padawan のほうが knight のスループットを若干上回っています。
上に書いた CPU 情報を見ると padawan のほうがクロック周波数は若干高いので、
ハードウェアサポート無しでは単純にクロック周波数の高い padawan が速かったということでしょうか。
3DES を使ったときの性能を見る限り CPU 自体の処理性能として knight と padawan に
それほど差はなさそうなので、AES-NI の有無による効果と言ってよさそうです。
ファイルの暗号化
ではこれが実用上どのくらいの差になるのかということで、
ほんの軽い程度ではありますが、ディスクI/Oを伴う暗号化速度を計測してみました。
80MB くらいの圧縮済みログを使います。
(暗号化したログを S3 に置いておくとかよくあるパターンだと思うので)
EBS ではなく ephemeral disk にファイルを置いて計測しました。
結果
下記グラフのような結果が出ました。
またしてもグラフに載せ忘れているのですが単位は sec です。
1ファイルの暗号化に5秒くらいの差がつくとなると、
大量のファイルを暗号化しながら処理するような環境では全体の処理時間に
かなりの影響を与えるのではないでしょうか。
まとめ
EC2 でも AES-NI の恩恵は受けられることが無事確認できました。
実際測定してみると、無視できないレベルで違いがあることが分かります。
AWS をはじめとしたクラウド環境は確かに物理マシンのことを考えなくて便利〜となりがちなのですが、
仮想マシン側から見える、"その向こう"の環境に思いを馳せておくと、
こういう細かい点で得できるんじゃないかなと思います。
AWS 側の物理環境もどんどん更新されているでしょうし、
使う側としてはぜひハードウェアサポートも含めた全力を引き出したいところです。
会そのものも、発表は正直だいぶ緊張したのですが、興味を持っていただけた方もいたようで良かったです。その後の懇親会も楽しかったです。
というわけで、楽しい場を提供してくださった cloudpack さん、ありがとうございました:)
追伸: 社会人になりました
学業を共にした Macbook を破壊してから早いもので半年が過ぎました。
冒頭で触れましたが昨年度で大学生を終えて社会人にクラスチェンジしました。
今のところサーバを dd で破壊したりはしていません。
社会人として、うっかりでマシンを破壊しない慎重さを身につけるべく日々がんばっています。
今後ともよろしくお願い致します。
dd と僕
自分のメインマシンこと MacBook Pro の SSD に Ubuntu インストールディスクを dd して破壊した。
正直書くのも憚られる話で、お前来年から本当に職業エンジニアになれんのって話なのだけど、
本当にクリティカルな状況下でやらかさないよう戒めとしてまとめることにした。
びっくりするほどレベルの低い話。
修士論文の提出も終わり、さてやっと研究室のサーバ環境を更新できるぜぐへへ、
とか思いながらとりあえず転がっていた HP MicroServer に Ubuntu を入れ、
作業用ストレージにしようとしていた。
自宅でも MicroServer を使っていたのでさくさくっと HDD を突っ込み、MicroServer には光学メディアドライブがないので USB メモリからインストールしようといつものようにインストールイメージをダウンロード。
光学メディアのないマシンにインストールを行う方法で代表的なものは、USB メモリ経由で行う方法か PXE ブートだろう。
以前作ってコメントアウト一行の解除で有効化できるようにしてあった PXE + TFTP 環境を使っていれば惨事は防げたと思う。
しかし僕は MBP に USB メモリを差し込み、いつものように dd で書き込みを行った。
行なってしまった。しかも sudo で。
一応それなりのサイズだし、USB2.0 経由なので書き込みにある程度時間がかかるはず。
だが実行のち、プロンプトが一瞬で戻ってきた。
「うおーずいぶん早いな、こんなもんだったっけ」とか思いつつ、ホームディレクトリに戻ろうと cd を入力してリターンキーを押す。
その瞬間ターミナルがグリッチした。
正確には、プロンプトの中にテキストカーソルがめり込んだ。
しかもリターンキーを叩くたびにめり込む箇所が変わる。なんだこれは。
えっ、と思いながら ls してみると、そこに表示されるリストの日本語は全て化け、サイズ表示さえもおかしなことになった。
はー、何かの拍子で LANG か文字コードが変わったりした？でもそんなことは一切してない、と思いながら echo $LANG したが、返ってくるのは ja_JP.UTF-8 という表示。
正直に言うと、最初にターミナルがグリッチした瞬間、自分が何をやったのか直感的には理解していたと思う。信じたくなかったけど。
もうこの段階で、ターミナルに残っていたコマンド履歴を見て、自分がしでかしたことを把握していた。既にパニック状態。
全てのアプリケーションはディスクアクセスした瞬間にクラッシュする。Chrome のタブさえ開けない。
システム領域はたぶんがっつり上書きされていて、メモリに乗っている部分だけが生きている状態なんだろうなと思った。
唯一使えたのは、起動したままのターミナルと夜フクロウくらいだった。
そのメモリ上の夜フクロウから最後に書き込んだのが下記。この投稿直後に夜フクロウもクラッシュした。
凄まじいやらかしをかました気がする
— Hok.H @ Kannyさん (@kani_b) 2013年2月4日凄まじいやらかしどころではなく、既に勝負はついていた。
ターミナルは生きているからまだファイルを移すことくらいはできるのでは、と思い
scp を試したら、最初の1ファイルが転送できたので少しテンションが上がった。
しかし次の瞬間に OS がフリーズした。
決着はついた。僕にできることはマシンの電源を切り、再び投入し、リンゴマークの後に表示される駐車禁止みたいなマークを眺めるだけだった。
その時の僕の様子は下記の tweet に詳しく記載されている。
@1vq9 @kani_b くんが実際にコマンドを実行してからしばらくランダムに動いて「うわぁー」か「どうしよう」をランダムに発するモブキャラになってた
— Tomotaka Itoさん (@tomotaka_ito) 2013年2月6日その日はもう何もできなかった。
小一時間ほど "どうしようBot" と化したあと、研究室の納会があったため偉大な先生方の前で先ほどの事象を報告し、「えっ論文のファイルは？？？」「論文本体は無事なんですがソースコードが…」みたいなやり取りをして、酒を飲みまくって寝た。
家に帰ってきて一応 Time Machine の日付を見たが、最後のバックアップは8月であった。
(家では基本的に MBP を断続的にしか使わないこともあり、中断されることが多かった)
その後しばらくの間はこの MBP について何かやる気が全く起きず、データ救出を試みたのは数日後。
とりあえず開腹して SSD を取り出し、testdisk をかける。
Deeper Search で複数パーティションが検出され、おおおーとテンションが上がったのもつかの間、
それは Lion がインストール時に作成する非常用ブートパーティションの残骸であった。
既に何をする気力も残っていないので、そのまま放置して、時間ができたら mountain lion でも入れなおすかーということになった。
事態が動いたのは最近。やっと OS を入れなおすくらいに気分が回復し、
mountain lion をダウンロードしてインストールをはじめる。
ここであることに気づいた。
「インストール時と全く同じセクタ、同じサイズでクイックフォーマットしてインストールすれば、インストール後に削除ファイル回復系のツールで取り出せるのでは？？？？？？？」
全く大したことではないのだがそれなりに現実味があることもあり、久々にテンションが上がった。
はやる気持ちで OS をインストールし、PhotoRec をかけてみる。
ものすごい勢いでファイルがヒットしまくる。
ここまでくるとテンションは上がりっぱなしで、7割くらい理由不明な勝利の予感を感じていた。
対象ファイル数が膨大なだけに、探すのには骨が折れそう(PhotoRec ではファイルツリーやファイル名までは再現されない)だが、この中に修士課程を共に過ごしたファイルがあるというだけで元気が出る。
一日くらいかけてサーチが完了した。数万件のファイルがヒットして復元されている。
最初のディレクトリを探す。うーんアプリケーション関連のファイルしかなさそうだ。しかし Omnigraffle の内部ファイルっぽいものなど、かつて自分が使っていた環境にあったものがそこにはあり、この調子なら自分のユーザディレクトリ下にあったファイルが見つかるのも時間の問題だろう。
どうやれば早いかな、plist ファイルとか結構あるけど捜索対象ではないし消してしまうか、日本語を含むファイル探せば早いかな、etc....
自分でホームディレクトリに FileVault (暗号化) をかけていてどう頑張っても復旧が無理ということに気づくまで、そう時間はかからなかった。
かくして、僕の MBP は修士課程2年間を共に戦った頃の記憶を全て失い転生した。
dd するときは指差し確認。人間はミスをせずにはいられない生き物ですね。
おしまい。
追記
この話を大学関係のちょっとアレな友人たちとしていたところ、
犯罪者っぽいTシャツを作ってくれた。いい友人に囲まれて幸せです。
http://clubt.jp/product/249779.html
大事なオペレーションをする日にはこのTシャツを着ようと思う。
追記2
ブックマークコメントで「バックアップ取ってないのがそもそもの問題」というご指摘を多数いただきました。
全くもってその通りなのですが、被害状況についてちょっと盛っちゃった感があるので追記しておきます。
実際のところ、本文にもありますが"8月までは TimeMachine でバックアップが取れていた"という状態で、
2年間のうち半分以上くらいは救い出せそうな気配です。(実際のところこれから先使うファイルが無さそうなのでリストアしてませんが、モノ自体はそれなりに堅牢なストレージにあります)
自宅外で使うことがほとんどで、自宅でもバックアップが完了する前に出かけてしまうことが多々あったので
クラウドストレージにでも突っ込んでおくべきでしたね。反省。
他にも、プレゼンに使うファイルだとか、そういうものは別なサーバに移してあったりもするので
被害数としては正直そんなに多くないかもなーと思っています。むしろ"やっちまった"ことへの精神的なダメージが。
お仕事として触るものは当然2重3重4重くらいまでバックアップは考えるもので、
心配性なので(説得力0だけど)管理していたサーバのバックアップ状況とかをモニタしたりしているものですが、
自分の環境となるとまーそんなに大したものないしなーと思ってしまう節がありました。失ってから気づくパターンですね。
論文そのものはもちろん git で自分のローカル以外の場所で管理していたので被害はなく、
実験しながら書き換えていたソースコードとか置いていたデータに被害がという感じでした。
まあ、バックアップは取れていて大前提ということは間違いないですね。
ということで、追記でした。ふげー。
「セキュリティとトレードオフ」について思うこと
「セキュリティと利便性はトレードオフだ」って半分本当で半分ウソだと思う。
少なくともセキュリティ技術を学ぶ上で教わるべき話じゃない。
エンジニアとしてセキュリティに携わるなら、はじめからこっちを立てればあっちが立たないという思考をしちゃいけなくて、
本当に必要なセキュリティレベルを考えながら限界まで利便性を向上させようとするのが正しい考え方じゃないのかな。そういった手段がないなら作るっていうことも当然選択肢には入る。トレードオフ思考が先頭に来てると、いつの間にか内部でコンセンサスをとったり、実装したり、監査したり、そういったコストばかりとのバランスを考えてしまう気がする。
「本当に必要なセキュリティレベルを考え」っていうのが実は一番難しいところだと思うけど。
たまにセキュリティに関わってる人で「僕らの仕事は足を引っ張ること」みたいなギャグみたいなこと言う人いるんだけど絶対違うよね。
適切なセキュリティレベルが保たれていて、必要に応じてちゃんとアクセスできるっていうのは、
情報を預ける側からすれば安心できるのはきっとそうだと思うんだけど、同時にそれを扱う側も安心して扱えるってことだと思う。
例えば顧客情報が流出したとして、「少なくとも内部から持ちだされたものじゃない」みたいなことが
すぐに明確に分かることって、扱う側からすると(もちろん外部からだからオッケーみたいな話じゃなく)「自分はやってない！」っていう悪魔の証明みたいなことしなくて済むからそれなりに安心できるはず。
もちろん扱う側の意識とか知識もとても重要だと思う。だから、そこも含めて。
難しいと思うけどやりがいはすごく感じる。
足を引っ張るんじゃなくて、むしろ僕らが見てるから、できることは安心してなんでもやっていいよ、って後押しするくらいの仕事がしたいよね、という話です。
VMware Fusion 上の VM を GUI 無しで走らせる
高校時代とか大学1,2年の頃はパソコンとか持ってるだけで楽しいというか、
物理マシンを触れるだけで満足していて、一時期は家にマシンが5台くらいあったんだけど、
趣味が一回りしたのか、最近はできるだけ環境を小さくしようとする傾向にある。
Windows のゲームはほとんどやらないからでかいマシンは従兄弟にあげた。
で、自宅の電気代の1.5割くらいは食べているであろうサーバを VM に移したくなった。
主に仕事でプロトコルレベルでデバッグしたい時に相手先として使ったり、かなり昔にホストしていた Web サイトなんかがある程度で、もう物理マシンで動かしている意味があまり無い。
家には Mac mini があって常時稼動しているのでここで VM 化してしまってサーバに使っている
マシンを止めて部屋の温度を下げようと思った。
長々と書いておいてやっと本題だけど、Mac の仮想化環境としては基本的に VMware Fusion を使っている。
インストールおわったらコンソールとかいらないんだけど、Fusion ではウィンドウ消しておくとかいうことができないので普段使うときに鬱陶しい。
バックグラウンド的に、というかウィンドウ無しで動かす方法ないかなーと思ってたら headless mode っていうのがあるらしい。
http://macosx.seesaa.net/article/115038173.html
http://www.fierycode.com/mac-osx-lion-vmware-ubuntu-server
vmrun というコマンドラインツールを使う。
/Library/Application\ Support/VMware\ Fusion/vmrun -T fusion start [vmx のパス] nogui
こんな感じで起動すると確かに vmware-vmx が走ってマシンが起動した。
ただ、すでに Fusion が起動した状態で走らせると Fusion 上では起動状態にならず、
その状態で選択すると Fusion が落ちる。どうやら vmrun との間で同期とかはとってないっぽい。
ちなみにその状態で再度 Fusion を起動すると再度ウィンドウが上がってしまって逆戻りする。
というわけで、起動する前に Fusion からこの VM の登録を削除(ファイルは残す)してやった状態で起動すると、Fusion 上には表示されないが裏では VM が走っている状態になった。良い。
暇をみて設定を移行してサーバマシンはシャットダウンしようと思う。おしまい。
