クラウド認証～エージェントと課金まで

御徒町@Serializable @okachimachiorz

@ichiro_satoh 課金のベースは、公平性の担保と客観性の維持なので、学術的な基礎基盤は必要だとは思います。このレベルから企業レベルでは対処のしようがないです。・・サービス料の決済は・・・ゲートウェイとか要りますけど、今全然ないですね。

御徒町@Serializable @okachimachiorz

それ話題になってた気がします。たしかちらっと聞きました。BT？たしか日本ではなかったと思います。RT @ichiro_satoh: 続き。それとクラウド向けの課金をするにしても、プロセッサを含む計算リソースの統一的な性能モデルが必要。

御徒町@Serializable @okachimachiorz

ないですね。もう適当。かなり適当。RT @u1: コストを明確化できるスキームを持ってる会社なんてどれだけいるのでしょうね・・・ @okachimachiorz: 課金は死ぬほどめんどくさいです。・・・そもそもチャージすべきコストベースが、なんだかわからないし。

tomo🐧@learning @cocoatomo

@okachimachiorz Kerberos って確認作業を認証サーバが一手に引き受けるのがポイントなので, 分散システムに向かない気がします.「ネットワーク上のクライアントの出入りは激しく数の上限も分からないが必要な認証は行いたい」という要請に答える理論が必要だと思います.

Shinpei Ohtani @shot6

@kkawamura @nemoton @okachimachiorz 水曜どうでしょうのノリでHadoopソースリーディングで全国行脚してもいいですよ。金夜スタート→土曜朝静岡、昼から名古屋、夜に大阪あたり、日曜朝に京都、昼から広島、最後に福岡、などｗ　しねますねｗ

御徒町@Serializable @okachimachiorz

同意。RT @cocoatomo: Kerberos って確認作業を認証サーバが一手に引き受けるのがポイントなので, 分散システムに向かない気がします.「ネットワーク上のクライアントの出入りは激しく数の上限も分からないが必要な認証は行いたい」という要請に答える理論が必要。

Masayoshi Hagiwara @masayh

そもそもDHTでのjoinでサーバ間の相互認証の仕組みはあるのですか？原理的には同じ気がします。@okachimachiorz .「ネットワーク上のクライアントの出入りは激しく数の上限も分からないが必要な認証は行いたい」

Shinpei Ohtani @shot6

@nemoton @kkawamura @okachimachiorz 昔やってましたｗ　まあ地方の空気感知るのも大事とおもいますです。福岡、大阪は既にいきましたけども。

御徒町@Serializable @okachimachiorz

@masayh 多分は今はないのではないかと思います。信頼N/W内という前提がある気がします。しかし、DCwiseになってくるとそうはいかないはずです。ここは今、皆さん、パフォーマンス優先で、見てみないふりに見えますねw。

Masayoshi Hagiwara @masayh

@okachimachiorz はいそうでしょうね。でもイントラネットの意味が薄れてくるとDCもあまり境界の意味がないと思います。なぜなら、エージェント指向が次に来るからです。そうした抽象化プログラミングモデルはもうすぐきます。

tomo🐧@learning @cocoatomo

今の自分の AD の理解だと, 1. Windows に AD アカウントでログイン. AD サーバから認証を受けチケットをもらう. 2. サービスにアクセスしたときに, サービスチケットを要求され, AD チケットを使って AD からそれをもらう. (続く)

tomo🐧@learning @cocoatomo

3. サービスにサービスチケットを渡す. 4. サービスが AD サーバにサービスチケットが正しいものが確認する. 5. OK なら晴れてサービスを受けられる. AS と TGT が分かれてないのは AD の実装上の話かな?

tomo🐧@learning @cocoatomo

#Kerberos の主目的はネットワーク上のサービスを 1 回の認証で使えるようにするシングルサインオンかな?

tomo🐧@learning @cocoatomo

ここで概要勉強中. #Kerberos Now Browsing: ケルベロス認証 - 情報セキュリティ入門：ITpro - http://tinyurl.com/cjcelb

御徒町@Serializable @okachimachiorz

@masayh おっしゃる通りですね。そもそも「ネットは信頼できない」という面でもエージェント指向の方が有利ですし。分散処理でのセキュリティにも重なりますね。

tomo🐧@learning @cocoatomo

クラウドで #Kerberos ってなんで問題になるんだろ? 1. Kerberos サーバに処理が集中し負荷が高まる. 負荷がそんなでもなければいいんだけどね. 実際のとこは知らない. 2. Kerberos サーバが落ちる可能性がある. 1 と似てる.

品川＠OS研究者 @utshina2

クラウド課金っていずれ定額制が一般的になるのではないでしょうか．ISPや携帯の料金が辿ったように．クラウドで従量制って怖くて使ってられない気がしいます．特に自分で使用量を制御できない場合に無限に elastic されたら… RT @ichiro_satoh: さらにその次は課金。

tomo🐧@learning @cocoatomo

エージェント指向って何ぞや? と思い調べてみると, ・代理性 ・知性 ・移動性 がエージェント.なんだタチコマのことか. Now Browsing: エージェント指向が目指すもの [連載第1回 サル思考とエージェント指向] - http://tinyurl.com/2d55g76

ICHIRO SATOH @ichiro_satoh

OS研究者としては定額制になると予想ですか。個人的には従量課金にこそクラウドの意味があると思っています。@shina_tsukuba: クラウド課金っていずれ定額制が一般的になるのではないでしょうか．ISPや携帯の料金が辿ったように．クラウドで従量制って怖くて使ってられない…

ICHIRO SATOH @ichiro_satoh

課金基準がメカニズムやが貧弱なので暫定的に定額制はあるかもしれませんが、クラウドのインフラコストは設備費用よりも電気代が高いことを考えると、従量課金にしないと辻褄が合わなくなりませんか。@shina_tsukuba

品川＠OS研究者 @utshina2

ユーザの視点に立って考えると，通信の場合以上に「使用量」という概念が何を指すのか直感的によく分からないので，それよりは定額制という分かりやすいプランを提示する方が安心して使えるという経営判断が行われるのではという予想です．もちろん「上限」 付きですが． @ichiro_satoh

tomo🐧@learning @cocoatomo

Telescript の項はクラウドに関心がある人は読んでおいた方がいいね. > @yutuki_r さん Now Browsing: エージェント指向が目指すもの [連載第3回 エージェント指向のゴール] - http://tinyurl.com/2cqz9tm

tomo🐧@learning @cocoatomo

内容はタイトルのまんまだが CPU やメモリモデルまで定義しているところがすごいパワー. この先が非常に楽しみ. - Coqによる暗号アルゴリズムの実装の安全性検証 http://icio.us/rzwqju

御徒町@Serializable @okachimachiorz

@ashigeru ちょっと、これどっかで議論したほうがいいね。HadoopのAA。Oozieの位置づけとか微妙。

Suguru ARAKAWA @ashigeru

@okachimachiorz 承知です>Oozie等。早めに目を通しておきます。原子化入れると運用スタックのaudit周辺まで影響しますねこれ