  |
はてなキーワード: 練習問題とは
勉強開始時は、プログラミング初学者。今はPandasやNumpyで遊んでいる。
この記事は自分のために書くが、今後受ける誰かのためになるなら幸いです。
https://www.pythonic-exam.com/exam
はじめにPythonチュートリアルを読みプログラミングを写経してみたものの、正直プログラミング初学者の自分にはチンプンカンプン。
（後ほどわかったけど、写経だとインデントミスがあったり、日本語誤訳や誤字が多かったりして、基礎力がない自分だと一人でカバーしきれなかった）
そこで、プログラミング初学者でも読めそうなPythonの本を読むことにした。
本をじっくり読むよりは、プログラミングって、Pythonってこんなものだよってことがわかって、Pythonチュートリアルを一人で読めたらいいかなと思い、基礎試験の範囲はカバーしていてあまり厚くない本を一読することにし、Amazon unlimited見つけたこのPython基の本を読んだ。
https://book.impress.co.jp/books/1115101060
本にあるプログラミングを写経しつつ読み、練習問題は一人でやってということを1週間ほどでやった。
この本はプログラミング初学者の自分でも一人で読み切ることはできたし、この本の練習問題くらいのコードなら一人でかけるようになった。
オブジェクト指向を意識して書かれた本らしいが、ぶっちゃけそのへんについてはわからない。
読み終わった後、Pythonチュートリアルを特に4章5章を一読。
すると、Pythonチュートリアルにはあるけど初学者向け本には載ってないことが結構あることに気づいた。
このチュートリアルを全部読んで把握するにはお上に言われている期間じゃとてもじゃないけど足りないし、
期間内試験に受かることが勉強する一番のモチベーションだしという事情と、
合格率高いし、「Python3エンジニア認定基礎試験はチョロい」みたいな記事が多いし、そんなに細かいこと聞かれないでしょという油断とで、
もう模試を受けてみた。
模擬試験は、おそらくランダムで40問選ばれていたので、サイトにある出題範囲通りでなかった。
模試を受けてわかったことは、当たり前かもしれないが本に載ってないこと結構聞かれる。
例えば、普段NumpyやPandasなどなどに甘えているせいかもしれないが、見たことないモジュールが出題されているなど。
謎訳が個人的に読みにくく、Pythonチュートリアルを英語で読んでいたが、試験はその日本語で出るので、日本語版を読むべき。
あと、主教材であるオライリー・ジャパン「Pythonチュートリアル 第3版」には載っているけれど、Pythonチュートリアルには載っていないこともあることに模試で気づいた。
模試の点数はあまり参考にせず不安だった箇所の復習に使い、再受験を3回行った。
模擬試験の問題バリエーションは多くないのか、かなりダブる問題があり、3回とも90点は超えたので本番受験してみることに。
サクッと解ける問題もあったけど、わからないなっていう問題が模試に比べると多かった。
例えば模試に比べると少し複雑な構造をしたプログラミング、など。
そして単純に覚えてない知識を問われてた部分も多々ある。
（オライリー・ジャパンの本を確認したところ、この本独自の言い回しかもしれない）
結果出た後Pythonプログラマーに聞いたら、何について聞かれているのかパッとわからないと言われた。
本番は細かいことを聞かれ、難易度1.5倍くらいになるので、Pythonチュートリアルは細かいところまで読み込むべし。
せめてメインの出題範囲である4章、5章はチュートリアルにあるプログラミングまで追うべき。
そして、どうしたらエラーが出て、どうしたらすべて実行されるのか、まで確認すべき。
正しい処理ばかりでなくて、たまにはわざとエラーを起こしてみた方がよかった。
エラーをあまり経験しておらず、どういうときにこのプログラムはつまるのかという想像力が欠けていて、そこがないと試験はつらかった。
過去問ほしいなと思うけど、試験側の問題の種類が多くないんだろうな。
（落ちた分際で偉そうに言うが、流行りの言語Pythonとはいえ、この試験逆に通って何が嬉しいのかわからない。）
https://docs.python.org/ja/3.5/tutorial/index.html
https://diver.diveintocode.jp/exam
https://ccie-go.com/python-exam-study/#i-10
https://togetter.com/li/1353321
Aの身長は150cm
Bの身長は155cm
Cの身長は160cm
Dの身長は165cm
この5人の中で、Cの次に背が高い人は？
これ
②「配列Aの中で、Xの値の次に{大きい/小さい/次に来るもの}は？」
の2通りの解釈で迷ってる人が多いんだろうが、今どちらも①はねーぞ
・「素数」は条件たり得ているが、「大きな」と言ってるから②である
だから答えはBと7
例えば、以下のようにすると①足り得る
Aの身長は150cm
Bの身長は151cm
Cの身長は180cm
Dの身長は185cm
Eの身長は190cm
平均身長：160cm
この5人の中で、Cの次に「平均身長より大きい人」は？
これは答えはD
「平均身長より大きい人」は大小ではなく、条件であるから②ではない
答えは13
「5より大きい素数」は大小ではなく、条件であるから②ではない
答え割れるよね〜じゃねーよ
ちなみに、①は「前の」と言えるが②は「前の」とは言わない
ex：「次に大きい人」「前に大きい人」
＿＿＿＿＿
取手、天王台、我孫子、北柏、柏、南柏、北小金、新松戸、馬橋、北松戸、松戸、金町、亀有、綾瀬、北千住、・・・
と停まる
このうち特快が停まるのは
１ 北千住
２ 金町
３ 柏
ボクも大学受験は私立文系型の勉強しかしていなかったので，大学にはいって数学をやり直しました．高校でちゃんとやっていないのなら，日本人が書いた教科書じゃなくてアメリカの大学学部の教科書（翻訳）がいいと思います．特に経済学用の数学の教科書がとっつきやすいかも（事例としても経済・経営問題がでてくるし）．古いですが私が学部生の時に使ったのは数学では次の2つです：
G.C.アーチボルド (著), リチャード・G.リプシー (著), 作間 逸雄 (翻訳)『入門経済数学 』(1) と(2), 1982/9
学生版でなく，練習問題の解答が附属している2分冊になっている通常版（コレ）が良いです．アマゾン中古で数百円で買えます．線形代数，微分積分，最適化問題，線形計画法等をカバーしています．
A.C. チャン (著), K. ウエインライト (著)『現代経済学の数学基礎〈上〉〈下〉』 単行本 – 2010/1/1
旧版なら，これもアマゾン中古で数百円で入手可．上の書籍がカバーしている項目のに加え，微分方程式と差分方程式が学べます．
T.H. Wonnacott, R.J. Wonnacott, Introductory Statistics for Business and Economics, 4th ed. 1990.
ある程度腰を据えて勉強するのなら大日本図書の数学シリーズ(高専生を想定して作成された)を強くオススメする．
https://www.dainippon-tosho.co.jp/college_math/
高専は，工学を学ぶ五年制(高校+短大)の大学である．本教科書シリーズを一通りマスターすると文字式の展開から複素関数論まで，高校数学のなかでも工学に必要な知識(≒数学科を除いた大学数学に必要な知識)+基礎的な大学数学(微積，線形代数，ベクトル解析，複素関数論，ラプラス・フーリエ変換)を学ぶことができる．
読者の対象はそれほどハイレベルではない(高専にもよるが，偏差値の低い高専は高校偏差値で55程度+大学受験を経験しない)ので，説明が平易で，例題も豊富．練習問題も非常に豊富である．それでいながら公式の導出はどれもしっかりと記されているので，腰を据えた勉強にも向いている．
全六冊だが，一日数時間をとって勉強できるのなら数週間で一冊を容易にマスターできるようになっている．
統計学を理解したいのならば，本シリーズの教科書を以下の順序で学べばよい．
基礎数学(高校数学の基礎が身についているのなら省略可)→線形代数(ベクトルの定義から線形写像)→応用数学(ベクトル解析の単元だけやればよい)→確率統計
簿記の勉強をしているけど些細なことにつまづいて全然先に進まない
まだ三級なのに
いま、参考書の仕訳のところを読んで、仕訳の練習問題を解いている
決算書に出てくる科目はある程度見たことがあって、よくある下のような表を思い浮かべればなんとなくわかるようなわからんような程度
でもこの表も、「資産」と「純資産」が違う列にあるのがよくわからない。どっちも資産って書いてあるのになんで負債と純資産が同じくくりなのか。
それに「資産」と同じ列にくるのが「収益」じゃなくて「費用」なのも統一感なくて気持ち悪い
貸方とか借方とかはよくわからないけど、「借方は左側の列」というのは覚えた。
売上100
入金100
みたいな問題で、なんで仕訳だと入金100が現金100になるのかが理解できない
入金という言葉は決算書の科目で見たことがないから何か違うのに変えるんだろうなぁというくらい
でも、入金されたなら当座なり普通なりとにかく預金じゃないの？
仕訳は暗記っていうらしいけど、何を暗記したらいいのか…
学生時代の専攻もあるけど、去年基本情報を受けた時は過去問3年分くらいを解答見ながら2〜3回解いたら受かったから、暗記はできる方だと思ってたのに、簿記三級は解答見てても理解が出来なくて全く頭に入ってこない
未来永劫受かる気がしない
元増田です。私の場合は個別指導塾だったので、受け持った生徒たちは大概、1時間1コマで週2～4コマ、週に2日は通ってきてる子供だったので、増田の家庭教師の条件とは全然違っていて、私の方が有利？だったんじゃないかと思います。増田の指摘通り、週1回1、2時間だと、多分キツイです…。
勉強をしなれていない子は、べんきょうたのしい！と思う頻度が少ない、次までに間が空いてしまうのは良くないように思います。あとは宿題を出すようにはしていました。テキストから練習問題を少し、その日に勉強して理解できたっぽいかなーと思える問題だけを選んで練習させることと、あとは英語については、レベルに応じて「目についた英単語を５ケノートに書き写してくるように」とか「目についた英語の文章を書き写してくる」とか、興味を引いてもらえそうな、ご褒美系の宿題も出しました。今言ってはジャスラック的にアレかもしれないけど、まぁ洋楽や流行りのJpopのアレをナニしてきたりとか…子供たちが好きなものを題材にすると、やっぱり抜群に食い付きが良かったです。
ただやっぱり週1はキツイと思うです。
現在、有料の「学びエイド」、無料の「Web玉塾」、無料の「Ｍａｎａｖｉｅ」家庭教師のトライがやっている無料の「Try it」、この4種の動画講義を主に利用している。
この4種の中で、学校の授業に1番近い作り方をしているのは、「Try it」である。最初に過去の講義の振り返り、今回のポイント、練習問題、振り返りと続く。1本の講義時間は10分から30分までである。
動画講義の中で1番短いのは、Web玉塾、学びエイドである。両者の動画講義は基本10分程度に長さを抑えてある。ポイントは1動画に1つから2つ。1度学校の授業を受けてから見る動画という印象だ。Web玉塾は、古くからある動画講義で、早口でコンパクトにまとめてある。学びエイドにある講義もWeb玉塾と同様の傾向がある。
Ｍａｎａｖｉｅは、授業に似た講義（Mundi先生の世界史、日本史、地理（途中））や学びエイド的な講義（とらますく先生の生物）、Web玉塾など、ネット上の無料動画講義をキュレーションしたサービスである。ユーザーインタフェースも整ってきている。
現在、私は理科高校教員として働いている。Ｍａｎａｖｉｅ、Web玉塾の生物動画講義を生徒に進めてみたが、どうも評判が良くない。なぜか考えていたところ、とらますく先生のブログの下記ページからヒントを得た。
http://genuinestudy.seesaa.net/article/456325367.html
上記リンクを読み、私が出した結論は、Web玉塾、Ｍａｎａｖｉｅの生物動画講義は、高校の生徒にとり早すぎるということだった。
この発見から、次は家庭教師のトライの「try it」の生物講義を進めてみようと考えている。生物を一度学んだものにとっては、「try it」の講義は遅すぎる。しかし、私の仮説が正しければ、高校生には講義スピードの遅い「try it」は受け入れられるかもしれない。
動画講義を作る人は、塾の先生や教育に燃えたボランティアが多い。そのため、動画をなるべくコンパクトにし、勉強の時間対効率を高めるよう作られていると私には感じられる。
しかし、多くの講義動画をみて私が感じたのは、長い動画にも見やすいものがあるということだ。特に、ＭａｎａｖｉｅのMundi先生の動画は、世界史や日本史に対する、Mundi先生の愛情が溢れている。このため、長くても見れる。
「try it」を見ていると、多少時間が長くてもゆっくり（20から30分程度）1つの事柄を説明しているため、授業作りのヒントが得られることも多い。長い（20から30分程度）の講義動画の需要もあると感じた。
私に文才はない。というか、ある程度の文章を書いたことがない。いや、書いたことだけではなく、読んだこともない。なぜ読まないのか。それは読んでいても直前のことを忘れてしまう自分の頭のせいだろうか。それとも、小説は読んでも何の足しにもならないと思っているせいだろうか。そんな理由ではなく、ただ単に読んでいると文字を読んでいると無条件に眠くなるからだろうか。とにかく、私は本を読むということができない。こう言うと、学校の教科書とかは読めたのか？と聞かれるが、あれば大丈夫であった。多分、学校の教科書の内容は、一行一行理解しようとして読んでいたし、所々に出現する練習問題のおかげで読めていたんだろう。私には小説や新書のような本は、一行一行真剣に読むことができない。それは、学校で試験のために勉強する切羽詰まった感もないし、小説は注意深く読むには長過ぎるし、注意深く読んでいると細かい表現や統一感の無さに苛つく。では小説に理解を確かめる問題があったらどうだろうか。さっき一瞬良いと思ったのだが、小説にそういうものがあったとしても自分は読まない。断言できる。新書にあったらどうだろうか。うん、読まない。教科書が読めた理由を考えて、それを小説、新書に適応したら、自分が読めるようになるかを考えたが、適応したところで読まない。教科書が読めた理由はやっぱり、やらなければならなかったからという気がしてきた。読めない、いや、読まない理由は単純であった、私は怠け者だから、自分にそれが必要になるまで拒否していただけだったようだ。
いや、おかしいではないか。自分は怠け者なのに、なぜこんな文章を大晦日に書いているんだ。この文章を書く必要性なんて全く無い、むしろ、これを書いている時間はテレビでも見てコタツで猫と遊んでいる方が、怠け者のあるべき姿ではないのか。怠け者と猫とコタツ。今すぐ手をとめるべきであろう。しかし、書き続けしまう。おお、もしやこれが世に言う承認欲というものを得んとする行為なのか。承認されたいと願う心は、こうも人間を動かすのか。
本当に承認されたいだけで、こんな文章を書いたとは思えなくなってきた。おそらく承認されると人は気分が良くなるのだろう。その気持ちの良さを得たいがために、承認されたいよーと思うんだろう。ここで、推量を使っているのは、自分がまだ承認されることが気持ちが良いということをネットでも現実でも体験をした記憶がないからである。現実で認められたことがないんなんて可哀想な人だなと思われるかも知れないが、可哀想なのだ。12月31日にこんな文章を書いているんだから、現実の方はお察しだろう。ネットの方でも、twitterやinstagramはアカウントをとってから、一度も投稿をしておらず、好きなユーザーの投稿をおっかけることだけに使っている。twitterもinstagramも自分から投稿しない理由を考えてみるに、自分には人との繋がりが乏しく、どうせ投稿しても誰も見ないだろうという考えを持っているのでは。ということは、見てくれる人がいれば、投稿しそうな気もする。この見て欲しいという欲求は承認欲では無い気がする。なぜなら、私は、見てくれるという行為だけでいい。見た結果、何とも思わなくても良い。ただ見てくれただけで嬉しい。コメントなんかで批難とか批評とか反応してくれたら、もっと嬉しい。貶されても良いと思っている、この思いは承認欲求がなすわざなのか分からない。
自分はタダのかまってちゃんなのか。少考し違うと結論。例えばこの文章の総閲覧者数が見えたとして、それが「3人」だったとしても、この文章を書いて良かったと思える。上にも書いたが反応は無くても構わない。その上、おそらくその3人は誰も最後まで読んでいないのだろうと思うが、一部分だけでも目を通してくれたことを嬉しく思う。では閲覧者数が「0人」だったらどうだろうか。かなしい。1人でもいいから、この文章が存在したことを認識して欲しい。10秒で記憶の彼方にいっても構わないから。この0人は悲しいというところから、この書くという作業が楽しくて楽しくてやっているわけではないことになる。
ここらで怠け者の本分がでてきて、めんどくさくなってきた。猫と寝ようっと。
読んだ。
その時のことを思い出して、懐かしいような、こそばゆいような気持ちになった。
高認の過去問題集の表紙デザイン、七年前と変わってないんだな……。
など、今まであまり身近に感じたことがなかったタレントさんに対して一気に親近感を覚えてしまった。
かあい氏は今回の高認試験で、惜しくも数学のみ不合格だったようだ。
かあい氏がどのように勉強されたのか、ブログの過去記事をまだ読んでいないため不明だが、高校一年生の一学期で中退し、何もかもチンプンカンプンの状態で勉強を始めた私の場合はどのようにしたのかを僭越ながら書いておきたい。
まず私は新大久保にある教科書販売店に行き、棚にずらりと並ぶ各社の教科書の中から、最も易しそうで最もページ数が少ない「数学 I・A」の教科書を選び購入した。
そして最初から最後まで精読しつつ、すべての練習問題を解いた。
その教科書はイラストが豊富で字も大きく、パンフレットなみの薄さだったので、自分でもちょっと頑張れば最後まで読めるかも……と思えたのが良かったんだと思う。
数学に対する苦手意識が強いあまり、はじめは教科書を見るだけで冷や汗が吹き出し、吐き気を催すほどだったが、一周目をなんとか終えたときは驚くほどの達成感があった。
最終的に、教科書を四周した。
四周目には、一周目であんなに苦戦していた練習問題も瞬時に解けるようになっていた（問題と答えをすべて覚えてしまったというのもあるが）。
しかし数学に勉強時間を割きすぎた結果、他の教科は準備不足となり、高認試験そのものは不合格。
惨憺たる結果に終わった（こういう要領の悪さが私が中卒になった原因のひとつなんだろうなー）。
というわけで、高認の数学は過去問題集だけだと解けないかもしれないが、教科書を使い繰り返し練習問題を解けば私のようなアホでも点数はとれたという話。
最後に。
あいつらは「批判」をすっごい悪いことって意味で使ってるの。
「批判」は和を乱すとか喧嘩を売るって意味でしかない。ケチをつける。因縁をつける。人の気分を悪くする。
批判は、すごくネガティブな、ピースフルでない、縁起の悪い行いなわけ。喧嘩とかケチ付けってことなわけ。
と、ここのコメントの1つ
研究者の頭脳と時間を、違うことに使いすぎている - 日経テクノロジーオンライン → ブコメ
基礎研究と応用研究、政治家はアカデミズムと算数ドリルがまだ区別できておらず「基礎なんかすっ飛ばして最初から応用問題が解けた方が効率よいし偉くね？」って本気で思ってそうなくらい、基礎研究軽視だからなー
2017/06/24 17:10
なんで歴代ノーベル賞受賞者の面々が口を揃えて異口同音に「日本は基礎研究に予算かけなさすぎ」って叫んでるのに、政治が一向に基礎研究への予算配分増に対して及び腰なのか、
一方で金欠だ振興費はもう頭打ちだと言う割に「チョコレートで脳が若返る」とかいう、明治のPRにノせられスライドだけ無駄に立派なトンデモ似非研究に内閣府が飛び付いて、予算がすんなりタンマリ通るのか、自分の中で勝手に謎が氷解した。
いつもなら「選ぶ側の政治家が科学や研究学問に対して無知無理解だから」「真偽を判断するだけの科学リテラシーと知識が無いから」で済まされて、最終的に「日本の政治家がバカばかりなのが悪い」と結論づけられるが、
多分それだけじゃない。使ってる言語体系と価値観の相違も勘定に入れるべきだったんだ。
つまり、内閣府の皆さんや現行の政治家の皆さんの多くが「基礎研究」「応用研究」の頭に付く「基礎/応用」という修飾語を、我々と違うニュアンスで捉えてるかもしれない、ってことだ。
・「基礎研究」と「応用研究」（大学や研究機関）
・「基礎問題」と「応用問題」（数学の問題集）
似てるようで全く異なる両者を、同じ意味でイメージしていらっしゃる可能性が非常に高いかもしれない…ってことだ。
つまり
「基礎研究というものは、延々と3+(-4)=-1… みたいな、計算ドリル初歩の練習問題を繰り返してつまづいている段階であり、それすらすぐ正答できないという事は無知で後進的で恥ずべきこと。
基礎なんかはもうとっくに出来てる前提で、応用研究（問題）がスラスラ解けるようになる事が到達目標であり良いこと。だから限られた研究予算は、基礎研究（問題）なんかをいつまでもダラダラやってる子（大学）よりも、
成果がすぐ見える応用研究（問題）をいっぱい手がけてる優秀な子（大学）に優先して配分するよ！」…という盛大な勘違い価値観のまま、表彰対象を選んでる可能性がある。
…いやそれも「連中が無知なのには変わりないだろ」と突っ込まれるかもしれないが、純粋に知らないのと、知ったつもりで誤解したままなのでは話が別だ。
もし「基礎＜応用」という上記のニュアンスで捉えている人が多かったら、科学者の"基礎研究を大事にしろ"の声が政治家に届かない理由も分かる。
"基礎研究なんて膨大な無駄の中からほんの少し凄いものが出てくるって世界(id:k_oniisan)"っていう正論も、「基礎の段でつまづいてるような出来の悪い子が、こづかい減らされるのを恐れて出来ない理由と言い訳を並べている」
としか受け取られていないかもしれんわけだ。たまーに偉いノーベル賞受賞者の先生が擁護して同じことを言っても、「出来の悪い子を、自分の身内やお友達や生徒だからって庇い立てしてるだけだ」と見做されているわけだ。
他方、基礎を終わらせて、もしくは基礎を飛び級して、成果の出る研究、金になる研究、応用研究に軸足を移し、先駆けて沢山手がけている子こそが優秀であり、高効率であり、限られた科研費の優先投資先として
相応しいのだと。そういうロジックで選んでるのだとしたら、民間企業協力のキャッチーな予備実験や仮説もどきの方が最先端研究だと持て囃されるのも実に納得だ。
そりゃ平行線にもなるわ。
書いてて絶望的になってきた。自分だけの思い込みかもしれないけど、これで科学立国とかマジで無理ゲーじゃね？
思った以上に賛否色々とブコメ、トラバを頂き、話題をすぐ畳むのが勿体なくなったので折角もう少し風呂敷広げてみよう（広げた後に収拾する気があるとは言ってない）
・id:outalaw 「予算」という言葉がすれ違っていそう。科学者たちは恒久的な人件費を含めているが、行政は一時的な雇用費や物品費こそ予算と捉えており、行政のいう予算は横ばいだが科学者のいう予算は減り研究時間も減っている。
・id:death6coin トランプアメリカはもっと低い次元にいそう／http://www.nistep.go.jp/archives/32530によれば予算的には減っていないが出どころが変化しており、研究者に成果へのプレッシャーがあるのではないかとの分析がされていた。
確かにその可能性も高そう。年度毎に補助金申請書を書き直さなくてもよい永続的フローが保障される事を要求する研究者サイドと、◯期活動分のキャッシュを確保することに奔走し、科研費増なんて出来るわけがない現実を見据えてる政治家サイド。
かたや「基礎研究への予算が増えない」と嘆き、かたや「予算は水準維持してる」と主張するのも、どちらかが嘘付きって事ではないはず。おなじ「金」のことを話してるんだからすれ違うはずがないと思いきや、両者の中で定義が違うままと。
で、河野太郎の研究者の皆様シリーズもまた、ブクマ上位によく来る人気エントリだが、結局できる事は"成果を生まない大型プロジェクトをつぶしてほかのことに振り替えるか、または成果を生まない研究者の予算をほかに振り替えるか"
実際上記の通りプレッシャーかかってますね
*id:kaeuta 馬鹿にしたい気持ちはわかるが、今の政権は経済産業寄りという点に尽きる気が。国民感情的に「膨大な無駄」が許される状況ではなく、基礎研究がすぐに金を生まない以上、金になりやすい応用研究が推進されるのだろう
*id:mainasuplus 増田にもあるけど、短期的に金になると想定される分野にしか研究費を突っ込みたくないのだろう。基礎研究や文系学問に研究費が落ちてこないのはほぼこれに尽きると思う。
予算は限られてて、社会保障費並の伸び率で野放図に増やすわけにはいかない。じゃけんせめて、振り分ける対象の厳選仕分けと優先順位付けくらいきちんとしましょうね～ という大筋は正しい。
が、それでも「基礎研究に割り振る比率はもう十分与えたから、与えられた枠内で工夫するか減らすかしてね」には強く反対する。
また抽象的な例え話に飛ぶが、国民も政府も喉が渇いてて、収穫すればすぐ生食できて喉が潤う万能フルーツ『成果』の大規模栽培を皆が渇望しているわけで。
収量予想や収穫期限コミットまで厳しくガン詰めされているので、使える湯水（金）も限られ、なおさら『成果』を優先栽培する以外に選択肢はないわけで。
でも、その『成果』を栽培するにあたって必須となる土づくりと肥料、その名も『基礎研究』…これは今すぐ食えるモノじゃないし成功の保障も低いから、金かけるのは後回しにしてね。そう言ってるわけだ。
もしこれから科学事業を再び仕分けていくにしろ、まかり間違って奇跡が起き科学振興予算が倍増するにしろ、上記の思想ベースである限り、どれだけ湯水の如き金があっても、きっと土壌と肥料は最後まで後回しで、
皆こぞって効率良い『成果』の密植技術開発に明け暮れるのだろうね。やがてサイエンスという土壌は、キャパを超えて過剰密植された『成果』に養分を吸われて徐々に痩せてゆき、追肥もされないので
最期は何も生えない不毛の大地だけが残りましたとさ。めでたしめでたし。
これには強く同意する。事業仕分けとかで管轄範囲の権益を侵さない限りは、知った上で正しく確信犯として野放しにしてる感
「ボケ、痴呆→認知症」っていう事例もあることだし、たかが言葉遊されど言葉遊び、形からでも変えてみる意味はあるかもね。
但し、「障がい者、子ども、メクラチビゴミムシダマシ」のように、無理に言葉狩りして理念が追い付いてない、仏像彫って魂入れずだと反感を買うおそれもあるね
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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
