スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
11/24/03:11 [PR] |
09/20/15:46 「技術的に可能か?」という質問について立場上、時々別のPMから 「……というのは、技術的に可能でしょうか?」 と相談を受ける。 こういった質問への回答は一瞬戸惑うことが多い。 なぜならば、文字通り質問を解釈すべきでない時が多々あるからだ。 世の中で実現されている技術であれば、それは”技術的”には可能であろう。 ただ、その情報だけでそのPMが判断を下すことは適切だろうか? 技術的には可能でも、自社の得意分野と異なれば技術力的に不可能なこともある。 そこを意図するのであれば、 「……というのは、ウチの技術力的に可能でしょうか?」 と聞いてほしい。 さらに、技術力的に可能だとしても、現実の制約条件のもとでは不可能ということもある。 例えば、1から10万の数字を計算機で足していくというプランについて考えてみよう。 足し算するというのは、理屈上どんな数字であっても可能なので、技術的には可能だ。 また、大抵の人は、計算機を使って、足し算をする力はあるから、技術力的にも可能だ。 ただ、現実として、各種制約条件からその案を採用することは不可能かもしれない。 制約条件や目標を意識する上で、PMであればおそらく次の3つの視点はもっているだろう。 もともとは製造業の世界の用語だが、今では広くビジネスの世界全体で用いられているいわゆるQCDというものだ。 1.Quality(品質) 2.Cost(費用) 3.Delivery(納期) 前述のプランは、計算間違いが起きる可能性が高く品質的にも問題があるかもしれないし、単純作業ではあるが予想以上に人件費もかかるかもしれないし、正確に計算が完了するまでの時間も結構かかるかもしれない。つまり、どのような制約条件や目標のもとで考えるかによって答えは異なる。 そこを意図するのであれば、 「……というのは、…という品質で、…くらいのコストで….までに実現することは、ウチの技術力的に可能でしょうか?」 と聞いてほしい。 先ほどの1から10万の数字を計算機で足していくというプランであれば、例えば 「1から10万の数字を計算機で足していくというプランを、絶対に間違いないレベルで、アルバイトへの支払いを1,000円で、30分後までに完了することはウチの技術力的に可能でしょうか?」 と聞かれたら、不可能と答えるだろう。 そんなわけで、可能かどうかの話をする場合には、制約条件をどこに設定するかそれを共有することが大事だよ、という話。 ちなみに、蛇足だけど、もしも目指すところが、1から10万の数字を足した結果を単に得たいだけなら、 (100000*100001)/2 で簡単に求められるね。目的が結果を得るだけなら計算機で足す実行プランがそもそも間違ってる。その可能性まで考えると・・・ 「...という目的のために……というプランを考えています。そのプランを…という品質で、…くらいのコストで….までに実現することは、ウチの技術力的に可能でしょうか?」 ときいてくれれば、よりよい代替案を出すチャンスも得られるかもしれない。
PR
|
08/02/09:34 正確には暗号化とメッセージダイジェストは異なるさて、前回、「パスワードを一方向暗号化しても簡単なパスワードを使っていたら意味がない」という記事を書いた。 話をわかりやすくするために「暗号化」という言葉を用いたが、 専門用語で言えば、md5 hashで生成されるものは暗号ではなくメッセージダイジェストと呼ばれるものだ。 確かに、両者ともに、特殊な関数を用いて平文を変換するという意味では同じではある。 しかし、メッセージダイジェストは世界中どこであっても、inputが同じで、かつ、同じ生成関数を用いた場合には同じ結果が得られるのに対して、暗号化というものはそもそも特殊な鍵を用いて行うのでその鍵(ロジックも)を知らない限り同じ結果が得られないという点で異なる。 メッセージダイジェストは、同じinputに対して、同じ結果が保証されているがゆえに改ざんされているかのチェックなどに利用されることも多い。 例えば、前回紹介したmd5は、どんな長さの平文のinputでも128ビットのメッセージダイジェストを生成する。このビット数が決まっていることによる利点は多い。 例えば、パスワードを平文ではなく、暗号化(正確にはメッセージダイジェスト生成)によって保存しようとした場合に、当然DBのパスワード保存用のフィールドを用意することになるが、これが仮にmd5でhashを作成すると決めている場合には、パスワードの長短に関係なく、128ビットを格納できる領域だけを確保すれば良い。DB設計を経験したものであれば、この利点には大きく頷けることだろう。 そのメッセージダイジェストだが、いろいろと種類がある。 代表的なものを書いておく。 (1) md5 これはRSA社が開発したもので128ビットのメッセージダイジェストを生成する。 他にもmd4とかmd2とかもある。 (2) SHA-1 160ビットのメッセージダイジェストを生成する。 最近、ハイスペックマシンの登場によりもう160ビットだと危ないね、と言われ始めている。 (3)SHA-2 SHA-1のアルゴリズムはそのままで、メッセージダイジェストのビット数だけ増やしたもの。 224,256,384,512のビットのいずれかでメッセージダイジェストを作成することができる。 (4)SHA-3 SHA-1とSHA-2とは別のアルゴリズムを使おうということで始まった試み。 ということで、誤解があるといけないので前回の補足として 正確には暗号化とメッセージダイジェストは異なる というお話でした。
|
08/01/15:32 パスワードを一方向暗号化しても簡単なパスワードを使っていたら意味がない皆さんは、DBにパスワードを格納する時、暗号化していますでしょうか?
基本的に特殊な要件が無い限りは、一方向の暗号化をすべきです。 どうしても、要件的に復号できる必要がある場合は、仕方が無いので復号可能な暗号化を用いましょう。 ITリテラシがないユーザーが直接データベースに入ってパスワードを書き換えることがあるケース等本当に稀なシーンにおいては平文で保存するということがあるかもしれません。 セキュリティの強度としては 1 1方向暗号化のパスワード 2 復号可能なパスワード 3 平文 という順になるかと思います。 さて、それでは、1方向の暗号化さえしておけば安心でしょうか? 実はそうではありません。 例えば、次の3つのmd5 hashされたパスワード、なんだか既視感ありませんでしょうか? たまにテスト環境とかで見かけますね。 (a) 21232f297a57a5a743894a0e4a801fc3 (b) 098f6bcd4621d373cade4e832627b4f6 (c) 5f4dcc3b5aa765d61d8327deb882cf99 これらの元となるパスワードは、それぞれ (a) admin (b) test (c) password になります。 一方向なのになぜわかったのか。 【答え】 メジャーなものはググれば出て来ます。 そうで無いものも世の中には暇な人がいるので地道に変換して辞書を作っている人がいます。 簡単なパスワードを使っていると、md5で一方向で暗号化されたところで、これではあまり意味がありませんね。 ん? DBの中身が見れている時点で元のパスワードなんてどうでも良い? そうですね。確かにそのアプリについてはその通りでしょう。 でも、本当に怖いのはそこから先なのです。 皆さん、世の中のいろんなアプリで当然パスワードは毎回違うものを使っていますよね?「いつものやつ」なんて言って使い回していないですよね? もしも使い回していたら、大変です。 その中の一つがハックされれば、その他のアプリについても同じパスワードを用いてアクセスが可能になってしまう可能性があります。 最近はログインIDをemailにしているアプリも多いですね。 そしたらIDを特定する負担も減るのでよりやりやすくなりますね。 もしも、そのemail自体のパスワードが「いつものやつ」を使っていたら最悪です。 たまたま慎重にパスワードを「いつものやつ」とは異なるもので登録していたアプリも、メールを利用したパスワードの再発行機能などでパスワードをリセットされてしまいます。 ということで、パスワードにはいろいろと気を使う必要がありますね、という話。 【追記】 次の記事で「正確には暗号化とメッセージダイジェストは異なる」という話を書いてます。
|
07/04/16:30 vagrant boxで何度もスクリプトをテストしたいなら最近、chefとかサーバーの管理(構築)を自動化するのが流行っていますね。 で、それぞれの形式に合わせてスクリプトを書いたりすると思いますが、いきなり本番サーバーに適用する人はいませんね。 まずは、ローカルの仮想サーバーでテスト、とするのが普通かと思います。 私は、packerで自分で作ったvagrantのboxをベースにいろいろと試しています。 で、まっさらな状態でスクリプトのテストしたいなら、不要なboxをvagrant destroyとかで一旦削除して、再度vagrant upで仮想サーバーを作成すればよいですね。 でも、実際にchefとかで一歩一歩スクリプトを書いては実行というのを繰り返したい時に何もテスト済みの最初のコードから実行する必要はありませんね。最終的には頭から流し直すにしても。 そんな時に便利なvagrant pluginの紹介です。 vagrant plugin install sahara これでsaharaというvagrant pluginがインストールされます。 使い方は超カンタン 今の状態まで何かあったらrollbackしたいというタイミングで vagrant sandbox on コマンドを打てばOK。 実行結果を永続的に反映したいなら vagrant sandbox commit 実行結果をロールバックしたいなら vagrant sandbox rollback とすれば良いですね。 試行錯誤するsandboxモードから抜けるには vagrant sandbox off とすれば抜けられます。 とてもシンプルですが強力ですね。
|
06/16/13:23 CentOS7でifconfigとかnetstatとか使いたいなら皆さん、CentOS 7 使っていますか?
私も個人で使ったり、最近では仕事でセットアップしたり、chefの勉強で仮想環境で触ったりしています。 CentOS 7になって、名前が変わったコマンドがいくつかありますね。 ifconfigとかnetstatとか打ってもそんなのないよと怒られますね。 まだまだCentOS 6時代の記憶が鮮明すぎて、CentOS 7のコマンドなんてすぐにでてこないこともあります。 そんなあなたは、とりあえず、 yum install -y net-tools ということで、net-toolsというパッケージをインストールしておけば、 ifconfigとかnetstatとか使えるようになりますね。 まぁ、これらは廃止予定なので、使わないほうが良いんです(当たり前です)。 でも、人生の時間は1日24時間しかないので、機会がないとなかなか本気で覚える気になりませんね。 私も以前突然相談されたときにそのサーバーがCentOS7で、ヤバ、IPアドレス確認すらできない・・・とパニクったことがあります。(かっこ悪かったですね) ということで、今日は非推奨な逃げ道のご紹介。 近々、ちゃんと整理して覚えよう・・・
|