  |
はてなキーワード: 機密情報とは
時間課金だったり、萌えキャラで結構オススメされている事が多いVPS。
ただその実態としては、非常に悪徳な業者なので、軽く触ってみる程度だと問題ないだろうけれど、それ以上の利用は強くオススメ出来ない。
諸条件あると思いますが、CPUを100%使い切りする処理を継続していたら、事前警告なく、サーバを止められました。
こんな利用をしていたのは、CPUは共有ではないとされていたからなのだけれど…
https://megalodon.jp/2018-0114-1653-36/https://www.conoha.jp:443/faq/vps/
そんな事はお構いなしに停止させられました。それも夜中にね。
まぁ専有可能なリソースを100%使い切っても問題はないわけで、サーバの停止に対して不服を申し立てるも一切の応答なし。サーバ停止の事後連絡に対し返信をしようが、サポートへの問い合わせをしようがなしのつぶて。なので、利用者側に過失がある場合はもちろん、事業者側に過失があっても、お構いなしに機械的にサーバを事後連絡でばんばん止めてくる。
CPUの件は、全く以て対策になっていないと思うけれど、以下のFAQをしれっと削除していました。（「basic認証はできますか？」の下にあった）
CPUは共有ですか？
https://megalodon.jp/2018-0204-2144-52/https://www.conoha.jp:443/faq/vps/
いやー、せこすぎるよGMO。
しれっとFAQを共有のCPUですに書き換えるだけでも十分過ぎるくらい悪質だけれど、不都合だからと、いくらなんでも掲載を下ろしてしまうとは…
いやー、早急な改修というのは、隠蔽なんですね。GMOすごい。
一般的な仮想環境の場合、CPUをオーバーコミット（簡単にいうと、8個のCPUに9個以上のvCPUを必要とするゲストOSを起動してしまう）しているケースです。今更、共用云々ということを言ってきたので、この点具体的に聞いてみました。
ご担当者 様
いつもご利用いただき、まことにありがとうございます。
はい、見事に答えてもらえていません。
こちらとしては、契約するときのスペックに関わる重要事項だから聞いているのだけれど、どうやら、ご案内できかねる内容らしい。
厳密なことをいうと、HyperThreadingを利用していると厳密には1vCPUで0.5コアの共有割り当てな一方で、1vCPUで1コア近い処理が出来てしまうので影響がなくはないのですが、こちらの件だとHTに配慮して2コアのサーバを借りていたので、それも関係なかったりね…
ご担当者 様
いつもご利用いただき、まことにありがとうございます。
お問い合わせの件につきまして、すでにVPSの削除を
大変恐縮ではございますが、ご料金の調整につきましては
今後ともConoHaをよろしくお願いいたします。
─────────────────────────────
FAQ/よくあるご質問 https://www.conoha.jp/faq/
お問い合わせ info@conoha.jp
─────────────────────────────
おかげさまで22周年 すべての人にインターネット
■ GMO INTERNET GROUP ■ https://www.gmo.jp/
─────────────────────────────
機密情報に関する注意事項：このE-mailは、発信者が意図した
上記の使い方ですが、別に他のサーバに対するクラッキングをしているわけではないし、停止させられることはありません。念のため…（似た使い方をメジャーなA社、G社のパブリッククラウドや、S社のVPSでやってみましたがいずれも問題なし）
一般都民の関心なんてその程度だよね。でも関係者間では「オリンピックなんてムダ」とか「どうせ賄賂で買ったくせに」とかいうのはタブーだよ。
私は限りなく中枢部から遠いところにいるので、機密情報とか全然入ってこないけど、直接オリンピックに絡む部署に行きたくないからと人事異動の書類にオリンピックの悪口書きまくったら上司に怒られた。
周りにスポーツ好きとか招致に絡んだ人が多いせいか、皆オリンピックに期待して「絶対オリンピックやりたい」とかいうのが多くてお前らアホかと思う。
https://anond.hatelabo.jp/20170721000647
稲田防衛大臣の辞任会見における、再発防止策でもこれにそった形となった。
というものであった。そのために、辞任会見における再発防止策は
というようなものになった。
PKOを指揮管轄するのは統幕*1なのに、そこと上下ではなく並列組織である陸自をピンポイント指定してジャーナリスト氏は公文書開示請求を行った。
当然ながら日報は統幕が管理保管していたから、陸自は回覧されてきたものに目を通した後に破棄していたために、その通り破棄したと回答した。
全文公開された日報を見れば分かるように大量のページがあるものであり、日報だけにそれが次から次へとやってくる。しかも機密情報満載。正式な保管部署以外は、読み終われば、電子媒体なら削除、紙なら溶解だろう。
防衛省全体としては統幕で保管されきちんと情報保全しているのだから探せば出てきて当たり前で、河野太郎氏の指摘もあり、ジャーナリスト氏は陸自に開示請求をしていたがそれを超えて統幕というか防衛省全体としてはあることを公表した。
またさらにその公表の後に、業務に使うのかあるいはただの規則違反か、陸幕でも回ってきた日報を削除せずに個人的に残している人がいたことも明らかになった。個人が保管していただけのものなので行政文書に当たらないと
考えたのもあろうが、何より日報としては既に正式な統幕のものを公表していたから、特に何の発表もしなかった。そして後になってそのことも公表した。
これらが何故か資料隠し扱いをされてしまう。防衛省でなく陸自に対して情報公開請求をしてきたからそれに従った対応をしただけなのに。もし統幕と陸自が上下の組織ならそれでも出てきた可能性はあるが、組織図を見れば
分かるように上下ではないのだから、陸自に請求するというズレたことをすれば当初のような対応が規則通りということになる。防衛省とはいえお役所、決めごと通りにしか動けない。むしろ今回は裁量的に動き過ぎなくらい。
*1 http://www.clearing.mod.go.jp/hakusho_data/2014/pdf/26020202.pdf
書き溜めと推敲に思った以上に時間がかかったんで、とうに旬が過ぎた話題になるが
「『ウソをウソだと見抜ける人でないと難しい』という格言はもう賞味期限切れ」という意見に同意の声 - Togetter
趣旨には賛成も違和感。「嘘を嘘だと自分だけがたとえ見抜けたとしても、その他大勢の見抜けない人に結局巻き込まれて、自分も含め事態は悪化する」が現代においては事実だと感じる。自己責任の限界を言ってる
2017/01/28 13:12
これを見て痛く共感し、かつて自分がいた勤め先のことをありありと思い出したので、熱量が冷めないうちに書き残しておく。
大元の発言は、ただのひろゆきの責任逃れの詭弁でしかないが、これは何も2chやインターネットの中だけで起きてるんじゃなくて、
Post-truth時代においては社会のどこでも当たり前に起きていることなんだぞ、という警鐘と自戒を込めて。
※本エントリは、退職エントリ・ブラック企業自慢・詐欺まがい商法・愚痴日記のキメラとなっております
細かく書きすぎて特定される事や、業務上知り得た機密情報の線引き、やれ営業妨害だ名誉毀損だになると面倒なので書き方は一部婉曲し濁しているが、
前職は水廻り設備全般の保守点検業をやってる会社だった。無料マグネットシートの広告をよくポスト投函してくるあれ系列会社の小規模版と思って頂いて差し支えない。
ご多分に漏れず「水のプロ集団」をスローガンに、トイレや台所排水詰まりの24H対応承ります、を謳う、よくある地元中小企業だ。
そこでの何が気に入らなかったのか。起こったことを順に箇条書きにすると、
イソジン溶液に含まれるヨウ素の茶色を、酸化還元の化学反応で無色透明にすることは、小中学生の自由研究レベルで再現可能だ。
ビタミンC錠剤、レモン汁（キャンディも可）、魚飼育用カルキ抜きなどを放り込んでやれば済む話である。
参考：http://cs.kus.hokkyodai.ac.jp/tancyou/vol.47/iromagic.htm
が、現実に目の前にあったのは、そんな理科実験で素直に「すごーい！」と感動しちゃう事務社員たちと、
目の前の箱でその販売会社の名前をググれば検索候補に「マルチ」「インチキ」がすぐ出るような詐欺師集団を、平気で社内に招き入れる重役と、
その事実を蚊の消え入りそうな声で辛うじて主張しても結局誰一人説得できない、何の現状も変えられない自分だった。
全てを殺したいくらいに腹が立った。
そんなものにGOサインを出す上司たちも、騙されて買ってしまった上で笑ってる部長も、人のためを思っての事なら詐欺っても無罪かい！それで済んだら警察要らんわ！とツッコミ入れたいパートにも、
義務教育と大学で学んできたのに、そんな現状を何一つ覆せない、全面対決の構えで公に訴え出る覚悟もない、傾聴してもらえる程の信頼すら得られていない自分自身も。
分からずに招き入れてたとしたら、水のプロ集団（）失格もいいところだし、
分かった上で招き入れてたとしたら、無知な下っ端に買わせて搾り取ってやろうというそれ以上のドクズ確定、
どちらに転んでもプロとして、人として終わっている。
ただ一人だけ、そんな会社に30年来勤続し続けた最古参のC社員（仮名）が残した自嘲気味な言葉が今も強く残っている。
「ウチは確かに『水廻り仕事を承る集団』ではある。けど、今の現状はお世辞にも"プロ"集団 とは言えんなぁ」
なお、そのC社員は課長職までは上れたが、会社規定に基づいた役職定年により主査となり、管理職手当が無くなる事実上の減給降格の上、
パワハラ課長の属する部署の窓際に飛ばされ、24h緊急対応の出動要員として待機を命じられる人事異動を受けた。分かり易い追い出し部屋である。
もうやる気ないならさ、早急に「水の反社会的団体」か「水のチンピラ集団」に改名してくれませんかね？
阪神大震災当時のインフラ復旧にも尽力し社会貢献したことがご自慢らしいが、公共の福祉改善1件で他の違法行為諸々がチャラになるなら
山口組はとっくに日本最大の慈善事業団として表彰されてるわ。理由が面子の張り合いとはいえ、災害時は地元へ我先に物資押し付けするからな
消費者センター案件かと思って調べてはみたが、通報して立件に動いてもらえるのは
が証明できないと難しい、とのことだった。今回の場合、参加はあくまでも任意で強要はされていないし
参加者のリストを作ってる時点で充分気持ち悪いが、かといって不参加者に何か不利益が降り掛かったわけでもない。
よくよく考えると、脳内で吹き上がってキレてたのは自分一人だけで、即決買いしちゃうバカ部長はともかく、
科学根拠には疎いようなママさん女性陣は「すごい商品ね」と口では褒めながら、結局誰一人買ってなかった気がする。
必ずしも正しい知識がなくとも、そこまでカネかける価値がある物かの真贋をジャッジする知恵はあったのかもしれない。
そんな事も知らないのかと、無意識のうちに内心見下している自分がいたことは大いに反省すべきだろう。
結局「上から下まで揃いに揃ってこの程度のリテラシーじゃ、この会社も先は長くないな」と見限りを付けて、適当に愛想笑いしながら
内心だけで舌を出しさっさと転職活動を検討するのが一番だったのだろう。俺も実際そうしたしな。少し空白期間を作ってしまったが
参加者を報告させてた当時の社長は、何の成果を挙げたのかよく分からんまま在任3年ほどで退任し、
浄水器を騙されて買っちゃったバカ部長が後釜に就いて社長になってた。今はCSR活動の一環として、
会社向かいの公園ゴミ掃除や花壇の水やりを行ってのうのうと社会貢献していらっしゃるらしい。へー偉いですね（棒）
なお、会社名検索したところ、アルゴリズム変更でネガティブワードのサジェスト汚染が表に出にくいように
修正が加わったGoogleとYahoo!の結果は平和だったが、bingの方に「会社名 ブラック」が候補に出てた模様。
表立った事件報道もされてない段階の標準サジェスト候補に「ブラック」が出る時点で、普段からどんだけ
人に恨まれる会社経営やってるのかお察しだが、ニュースにも出た名だたる本場ブラック企業の実態に比べれば、
ここの小物ぶりなんてせいぜいが「ダークグレー企業」程度のものだろう。
なお、退職前にメールでこっそり「ブラック名指しされてますよ、なりふり構わないなら"逆SEO"なんてモノもありますよ」
ってこっそり業務改善提案を提出してどう出るか様子を伺ったところ、個人的観測範囲で2015年6月頃までは
「ブラック」が上位に来てたのが、「カイシャの評判」というen転職系列のレビューサイトに、それはそれはもう
綺麗な桜色の美しい書評が沢山寄せられて検索結果が変わっていた。分かりやすっ。
参考：削除跡地
地球連邦宇宙海兵隊が開発した、過酷環境における機動歩兵用強化防護服。
外惑星における高低温・低酸素・放射線から人体を保護しつつ、戦車に匹敵する装甲とジェットパックを駆使した高い機動性の両方の実現に成功している。
パワーワードスーツ部隊は4人1個小隊を格納したカプセルで目標地点の超高高度に接近した強襲揚陸艦から降下、作戦遂行後集合地点に設置した脱出ポッドで母艦に帰還という戦術を採用する。
パワーワードスーツ両肩のアタッチメントレールには作戦内容に応じてミサイルを含む多様な武器を装備することができ、火力による意図しない同士討ちを避けるべく歩兵同士は互いに1000メートル以上の距離を取りつつ行動するため、味方の状態は母艦を経由したHUD上のコマンドメッセージでしか把握することができない。これにより、戦況が悪化すると機動歩兵は強い孤独感と恐怖に苛まれる。パワーワードスーツ部隊が宇宙海兵隊最強の部隊でありながら大量のPTSD患者を出す所以である。
PTSDにまでは至らなくても、作戦終了時の歩兵のストレスは相当なもので、「無人在来線爆弾」「フレンズ細胞」「野沢雅子におしめを取り替えられた大塚明夫」「機密情報は紙でやりとり」「ヤリマンボウが新潟に漂着」「民意に反して支持を集める」など意味不明の言葉を皆一斉に口走るのが当たり前の光景となっている。
先月に発売された日本国有重工業清算事業団製のタクトスイッチ（黒）SKHPHNA313。
私には入手できなかった。初期ロットの３２５１０台は完売したそうだ。
今ではそれなりのコレクションになった。
私が生まれるより以前には多くの趣味人口のあった分野のようだが、昭
世代の違う親に言わせれば例えば、切手収集みたいなもののように目に
映るようだ。
デザインや絵柄しか違いのない切手に比べたらスイッチには、筐体を形
作る樹脂の手触りや質感、色、端子の鈍い輝き、そして何と言っても機
種による様々なクリック感。
大きなものではなく、かさばらないので例えば自動車のような趣味と比
べ所有するのに場所をとらず、多くの種類を所有できるのもいい。
採取した昆虫を陳列するかのように離れの書斎に並べてある、私の数多
くのコレクションの中からその日の気分で選んだお気に入りのスイッチ
を押すことにより、その感触を味わう。
冬の暖かい部屋のなか、柔らかな椅子にくつろぎ、ラヴェルのレコード
を掛けその単調な変わらないリズムに合わせ、スイッチを左手に取り、
クリック。
ところでスイッチ収集という趣味の市場は世の中に、昭和初期に急に現
れたらしい。
どういうわけかは不明である。はじめは細く好事家の間での国の生産計
画の情報などの会合やあるいはコレクションの展示会、交換会などが行
われていたようだ。
国立国会図書館に存在もするその会の名簿を調べると、参加者には国防
関係のテクノクラートや財閥系の重工業企業の社員の名前の存在が目立
つ。
市場の人数的には、その頃はこの趣味の市場は大きくは、なかったよう
である。
その後、先の大戦中の国家高揚のなか、敵性語であるのでスイッチとは
言わないが、このころではすでに開閉器収集というジャンルの趣味が市
民の間には広く存在した。
月刊開閉器句報、昭和１５年２月創刊号、も私のコレクションの一部だ。
さて、スイッチを手にとりながら、テレビジョンによるニュースに耳を
寄せると、本営の報道官が伝えている。
数年続くこの大戦の戦局は本営の発表によると、本日も快進のようだ。
先週も三沢基地より、北の方向への弾道ミサイルが２発発射された。
ニュースは続けて本営、および日本原子力研究製造開発機構の広報官ら
による記者会見を写している。
先の国会を通過した法案、憲法66条2項の改正を適用をした結果の条項
は、どうやら兵器を発射する装置を制御する管制官は日本の政府運営シ
一度外れた箍をはめること難しいことと同じように、多く憲法が改正さ
古くからのスイッチ収集家の私から見たら、必要性は感じられないのだ
が最近のスイッチの内部にはただのスイッチ以上の何らかの機構もある
ようだしまた、コンピューターネット上にある、政府の機密情報をリー
クする情報発信サイトによると、スイッチ部品の発売元、ディストリビ
ュータは各民間商事企業ではあるが、実は製造は全て国が一元して行っ
ているという話もある。
機能が増えるなら趣味の幅が広がるし、また国が製造管理しているなら
ば品質も安定するであろう、理由はわからないがコレクターとしては喜
ばしい、とだけしかその時は考えなかった。
そして私以外の多くのコレクターの手にも、押されるのを待つスイッチ
が多く、あるのだろう。
会社の上司たちが目の前で俺が聞いちゃいけなさそうな会社の機密情報を話そうとしてたので、
「あの、私席はずしましょうか？」と声をかけたら、「うわぁいたの！？」からの「増田くん気配断つのが上手すぎて怖いわー」と言われてしまった。
言い方的にも冗談半分ではあるだろうけど、好きで影が薄いんじゃないわい！とちょっと哀しかったので愚痴ってみる。
もともと1対1なら普通だけど、4,5人集まると途端に影が薄くなる。
後からその時盛り上がった話とかをしたときに「あれ、お前あの時いたっけ？」とか言われるタイプだ。
「いたよ」と主張すると、大抵しばらく考えて「あーあーあーあー！いたわ！いた！いないとおかしい！」とか言われるが、
その盛り上がった話題を最初に場に提供したのも、途中でいい感じに話題を連結させて盛り上げたのも俺だよ？と思ったりして寂しい思いをする。
会議でいいアイデアを出したのが他人の手柄になりかけたこともあった。
友人や恋人から教師、親、同僚、上司、取引先、店の常連さんまで、いろんな人から似たようなことを言われるので、
何人かに聞いてみたことがあるが、どうも場面を思い出した時の映像にいないか、背景に溶け込んでいて見つけられないらしい。
でも、いないとエピソードに齟齬が生じる程度にはやり取りに参加しているので、最初は別の人の発言かと思うのだけど、
よーく出来事を思い出していくと、壁のシミとか風景の一部だと思っていたところに急に出現して発言する感じで記憶の中に現れて、また消えていくそうだ。
それも大体が確信を持って俺だとわかるわけではなくて、状況証拠的におそらくここに当てはまる人物は増田だろう、みたいな感じらしい。
まったくもってひどい話である。
人混みで合流しようとして、こちらから相手は確認できているのに相手からはこちらが全然見つけられないのは最早いつものことだし、
「増田は？」「あれ、さっきまでそこにいたんだけど」とかもよく言われる。まだ3m圏内にいますよ。
車の後部座席に座ってたら「アレ？増田乗ってる？ヤベェ置いてきちゃった！」と言われたこともある。
「いや、いるよ」って言ったら運転してたやつが事故りそうな勢いでびっくりしてた。幽霊かっつーの。
子供のころはケイドロ中に警備の間をするっと通って特に走ることもなく囚人解放するのが得意だったけど、捕まってる仲間も接近に気付かなくて、タッチしたとき本気でビビられたりしてこっちもヒャンってなる。
小学生の時に、びっくりしすぎた女子が漏らしてしまって号泣して、一時期ケイドロ禁止になった。
子供は残酷なので、終わりの会で急遽始まった再発防止策会議で女子が言い出した、「増田くんをケイドロに参加させない」が支持されて先生が慌てて止めるというおまけつき。
これまでにも何度か原因を自分なりに考えてみたりしたけど、イマイチよくわからない。
見た目のモブ度が高すぎるということなのか？と思って、高校生のころに頑張ってちょっと奇抜な服を着てみたこともあるけど、
後日「あの時妙な恰好してきてたのお前だよな？」と別の友人が疑われていたのでその方向で頑張るのは早々にやめた。
別にずっと下向いてるわけでも、隅っこでうずくまってるわけでも、目を合わせないわけでもないし、発言しないわけでもない。
あー、でも、多人数だと自分がぐいぐい行くというよりは、場の空気が盛り上がってうまく回るように薪をくべたりするような意図の発言が多いかも？
なんにせよ存在感が薄いってことだとは思うのだが、生き物としてオーラとか発してる圧力みたいなものが弱いのかなー？だの、
すぐ見失われるのは、視線や意識の死角みたいな位置が落ち着くとかで、自然とそこに収まってるのかな？くらいしか思いつかなかった。
まあ、悪いことばかりでもなくて、
席や出席番号で機械的に当てていく先生にはあてられるけど、見回して雰囲気で指名する先生には一年間まったくあてられないこともあった。
多分普通なら見つかって叱られるようなことをスルーされて、お目こぼし状態になってるようなこともあると思う。
テーマパークや繁華街にデートに行くと「100%見失うから手を繋いでほしい」って言ってもらえるのも嬉しい。
それでも毎回3,4回は軽くはぐれるのだけれど。
----
追記：
すげーブクマついて目立ってる、やったね。慣れてないから気恥ずかしいけど。
会ったことないけど似たような人いっぱいいるだろ(共感くれよ)と思って書いた部分があったので、チラホラいて嬉しい。
仮に実際にニアミスしてもお互い気付かないだろうから、ネット越しで存在確認ができるのはとても良い。
自動ドア、エレベーター、あと「いらっしゃいませ」してくれないATMと、消えたら二度とつかないトイレのセンサーライトは我々の敵です。
コンビニの前でセンサーに向かって手を挙げながらぴょんぴょん跳ねたりとか日常茶飯事。ふと動いたときに実家の猫がびっくりして跳ねるのもよく見ます。
ブコメにあった、空気読みすぎとか、会話のキャッチボールしてないのでは？とかはちょっとドキっとした。
確かに、会話のキャッチボールをしてる人たちが取りこぼしたり失くしたボールを、キャッチボールの輪の中に投げ戻すようなことを言ってることが多いかも。会話の球拾い増田。
体育のバスケは試合中「ヘイパヘイパ」って言い続けてるだけで、全然ボールに触らない系プレイヤーでした。
自分に飛んできたパスを横から味方が華麗にカットしていったこともあったけど、イジメじゃないと信じてます。信じてますとも。
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
LoL日本鯖CBTが終わり、日本鯖への期待が高まってる状況で起きたLJL CS予選の騒動。
今回起こった騒動を詳しく知りたいなら
LJL公式声明、GAME WatchとAUTOMUTONの記事、KINGDOMの告発blog、そしてLoL速報の替え玉疑惑の記事
を読んでみると良いと思う。
過去の発表は見にくくなってて確認しづらいが、基本的にLJLの発表や声明は説明不足すぎるんだよ。
2014年のLJL Challenger Tournament決勝で某プレイヤーにELO Boostしてる疑惑がかかって辞退してぐだぐだになったときもほぼ説明なし。
2015年のApexR Gamingが後半のLJL大会に参加できなくなったときも「アンプロフェッショナル行為により」としか言ってなくて説明不足。
これらの事態が起こったときに公式声明だけじゃ、まっっったく何が起こってるかわからんかったからTwitterなどで情報収集してやっと何が起こったのかわかるんだ。
こんな声明と説明だけで終わらすなんて見てるファンをバカにしてんの？とそのとき思ったよ。
そして今回の騒動だ。
今回の疑惑はeスポーツとして重大問題なんだから、どんな経緯があってどんな調査したかくらい説明したって良いんじゃないか？
あと機密情報を漏洩した側は批判されるし、出場停止にされたのは仕方ないだろう。
ただLJL運営もあれだけ詳細な「機密情報」を漏洩されたんなら、その機密情報についてコメントしてくれよ。
何が建設的じゃなかったのか？どういうやりとりしたのかくらい教えてくれ。
本当にスポーツとしてやっていくなら、運営する側は見てるファンが納得できるように1から順番に論理だって説明しろ。
ファンはそういう不正や説明に敏感な相手をターゲットにしてると自覚してくれ。
そりゃ不正等の悪いイメージや詳細な調査はお金に直結するし綺麗事かもしれん。
参加してるチームや個人への敬意は持つ。やっぱうまい人のLoL見てて楽しいしさ。
ただLJL運営は「見てるファンに対して何とも思ってないんだな」と白ける気持ちが俺の中で決定付けられた。
誰も得しなかったが、唯一の救いは今週にLJL本選がなかったことだろう。
本メールならびに添付ファイルには機密の内容を含んでいる場合があります。
貴殿が意図された受取人でない場合、あるいは受領する権限がない場合、本メールに含まれる情報を利用、コピー、第三者に開示することは出来ません。
万が一誤って本メールを受領された場合には、誠にお手数ですが、直ちに送信者にご連絡頂き、かつ受領されたメールを直ちに破棄して頂きますようお願い致します。
会社単位で記載されている場合が多く、送信者も特に意識していないと思う。
結構ずうずうしい内容だなといつも感じている。
「第三者に開示することはできません」とか、ビジネス上での約束事や社会的モラルの問題で、最終的に判断するのはこちらでしょ。
受領する権限があったら開示しても良いんかいー！ みたいな。開示しないけどさ。
悪意のある人への抑止力にはなるのかもしれないけど、それを望むならもっと良い文章があるんでないかな。
まあコピペで使いまわされているだけか。。
ちなみに、この文章ってどのくらいの法的拘束力があるんでしょうかね。
追記：
他のメール見てたら良いのあった。こんな感じのグッド！
このE-mailには、機密情報が含まれている場合があります。
万が一、当方の手違いにより貴方様が当方が意図した受信者でない場合には、お手数をおかけいたしますが、速やかにこのE-mailを破棄していただきますようお願い申し上げます。
