JICS2013レポート(2) 3/4午後 Enterprise Sessions
AWSセキュリティープロセス概説
- Amazon 荒木さん
- 世界に広がるAWSインフラストラクチャー
- クラウド ≠ サーバ仮想化
- セルフサービス可能、使用分のみ支払い、スケールアップ/ダウン容易
- 仮想サーバーだけではないクラウドサービス群
- クラウドネイティブサービス
- AWS Security Center
- Security White Paper
- Risk, Compliance White Paper
- 定期的に更新
- 物理セキュリティー
- non-descript facilities: 一見してAWS DCとはわからない。看板を出さない。場所を教えない
- 周囲に対する堅牢な管理
- 厳格に管理された物理的アクセス
- 2つ以上のレベル・要素による認証(それ以上の場合もある)
- すべてのアクセスはログされ監視される
- EC2セキュリティー
- ネットワークセキュリティー
クラウドサービスとしてのdigital identity
- Active Directory ドメインを使っている人
- 中央システムとして、一部システムで〜 パラパラ 〜1/10以下
- AD: 昔はディレクトリサービスだった。2008年以降、ソリューション全体を指す
- ADFS federation service: identity federation 2003R2以降でサポート 〜 いまだ浸透していない
- Agenda
- パブリッククラウド上のIdPの役割とは?
- IdPの乱立は続くのか?
- Windows Azure Active Directoryとは?
- パブリッククラウド上のIdPの役割とは?
- サービスあるところIdPあり
- サービス(Service Provider: SP)には認証と認可がつきもの
- Facebook, Windows Live, google, Salesforce, MS Office 365
- これまでオンプレミスで増えてしまったIdPをどうするか? → パブリッククラウドでもくり返すのか??
- くり返されると困る
- オンプレミスでは乱立をどう回避したのか → 回避は……できませんでした……
- クレームベース(認証と認可の分離)
- 認証側と認可側に分離することが大前提。分かれていることが重要
- IdP: ユーザー認証、デバイス認証を行いトークン(assertion)を発行
- SP: トークンから本人を識別し、ロールを決定してアクセスを認可
- クレームとは「要求」のこと「これこれの情報を持って来い。うちが信頼しているIdPからでよろ」
- ユーザーはクレームを持ってIdPへ行く。IdPが認証を行う。トークン(署名済)にクレームを入れて渡す → SPはトークンを解析してクレームを取得。本人識別、ロール決定、アクセス認可
- IdPの認証結果に応じてSP側でロールを再計算可能
- SPにトークンを渡すのはユーザーであるのも重要。IdPとSP間は直接通信をする必要がない → SPからIdPに「これホント?」と聞きに行く必要がない
- クレームベースのメリット
- 会場でフェデレーション導入されている方 → ほとんどいない
- SEが理解できない → ローカル認証で行っちまえ、ってなっちゃってる
- MSのIdPプラットフォーム
- Microsoft Account (Windows Live ID) consumer
- Windows Azure Active Directory ┓ enterprise
- Windows Server Active Directory ┛ちょっと違うよ enterprise
- MS Server AD: MS全製品・全OSが対応している
- MS Account: メール、People, Calendar、Skydrive, Store
- MS Azure AD: SaaS認証: Windows Intune, Office 365, Dynamics CRM
- MS Server AD, Azure AD
- federation可能
- 人事メタデータからへの同期が可能
- Azure AD
- Directory
- マルチテナントに対応したディレクトリサービス
- AD LDS: ようするにLDAP
- オンプレミスADとの同期、フェデレーションが可能
- 多要素認証
- Access Control
- Graph API
- Odata V3
- オンプレミスADとの同期
- すでにオンプレミスSSOができている場合
- Azure ADと同期(Graph API, PowerShell, DirSync, Forefront Id Manager)
- 利点: 管理すべきリポジトリはオンプレミスのServer ADのみ
- まとめ
- Id federationを正しく理解しましょう
- public cloudのIdPをうまく使うには
- アプリをクレームベースに対応
- アプリとの互換性を確認
- 運用をイメージする
JICS2013レポート(1) 3/4午前 学認シンポジウム
3月4日〜5日、Japan Identity & Cloud Summit(JICS)に参加してきました。今回はNIIとOpenID Foundation Japanの共催で、産官学が集結する日本初のidentity summitとなったそうです。
4日はGeneral Track、5日はOpenID Hackathonを中心に参加しました。
当日取ったメモを公開します。間違いや発言意図と違うなどありましたらご指摘お願いします。
学認トラストフレームワーク
- 学認の定義
- SSOの運用主体
- 参加・運用ポリシーを定める
- 参加申請
- 正しく運用されているかチェック(アンケート)
- 学認はself-containedなTF
- 学認の与える漠とした信頼
- 学認に入ってIdPを運用している機関は信頼できる
- 学認に入ってSP(RP)を運用しているところは信頼できる
- OIX (OpenIdentityExchange)
- 学認の与える漠とした信頼
- TFの御利益
- SPはIdPのLoAについて一定の保証を得られる
- RPのサービスポシシー・セキュリティーポリシー・プライバシーポリシーの評価について一定の保証が得られる
- なんとなくの信頼ではなく監査による信頼性の保証
- OIXが学認のトラストチームを認定
- OIXと学認
- OIX: OpenIdentityExchange
- 学認とOIX
- 学認はOIXにspecial providerとして参加
- OIXは「学認のIdPに対してFICAM LoA1認定を行うアセッサ」を学認内で指定する
- LoA1
- 世界標準
- レベル1〜4
- 認定基準
- Governance(成熟度), Privacy, Technical
- OIXの審査基準を適用
- 学認の場合
- 学認アンケートにポジティブな答える出ればLoA1はOK
- 学認アンケート
- 組織の成熟度(Governance)を調査する手段
- きちんとIdPを運用しているか。文書化されているか
- Identity管理
- パスワード管理
- プライバシー
- テクニカル
- 組織の成熟度(Governance)を調査する手段
- 学認アンケート
- おおむねpositive
- 運用スコアつけてみた
学認R&D 2013春モデル
- 学認申請システム
- OpenIdP対応
- これまでは申請のためのアカウントをローカルに発行(メアド、パスワード)
- → OpenIdPで認証可能に
- OpenIdP: IdPを構築していない組織の人たちが試験的に利用できる
- 学認サービスの一部を利用可能
- 運用責任者
- 副運用担当者が指定可能: eppnがあれば主担当者が確認済みにできる
- 学認アンケート機能
- メタデータテスト作成
- mdui対応
- SAML V2.0 Metadadata Extensions for Login and Discovery User Interface Version 1.0
- IdPを見つけやすくなる
- mdui:DisplayName, Description, Keywords, Logo, PrivacyStatementURL
- IPHint, DomainHint, GeolocationHint
- ログイン時のIPアドレスやgeoロケーションでDSを選択
- SAML V2.0 Metadadata Extensions for Login and Discovery User Interface Version 1.0
- attribute-filter
- 利用可能なIdP/SPの設定を固別に可能
- IdPに対応していないSPを非表示
ケーススタディー中小大学の例
- 北見工業大学 升井さん
- 北見工業大学とは
- 北見: 札幌まで300km 特急で4時間半
- 1学部(工学部)/6学科の単科大学
- 教職員300人、学生・大学院性2300人
- 必要なライセンス数2600〜3500
- かかえていた問題
- 業務サーバーがばらばら → ID/PWもばらばら
- LMS,教務管理、語学演習、図書館、物品請求、出張申請、サイボウズなどなど
- 採用したソリューション
- SSO・ID統合管理: OSSTech OpenAM、代理認証、Shibboleth連携
- ID統合管理: LDAPマネージャー
- サーバー統合、仮想化
- データの流れ
- 「ID連携する」と言うとアブナクなるんじゃないかという心配が出るので学内に説明が必要だった
- SSO実装の方針: SSO 代理認証方式、チケットで
- 導入までのタイムライン
- 苦労話
- 重要なサーバほど、古くて融通が効かない → Win2000だったり
- 事務職員の配置転換(3年) → システムに精通している人がいなくなる
- 学内への接し方: まあまあ、あの先生がそうおっしゃるならという気の使い方が重要
- Shibboleth連携
- 学内SSOにログイン後、Shibboleth連携ボタンをクリック
- 本学SPを立て、そこから本学IdPでいったん認証、そのセッション情報をクライアントへ送信
高専のID連携
- 校内LANシステム更新計画(平成21年度)
- 認証サーバ
- OpenLDAP, FreeRADIUS, Shibboleth, UnifIDone
- 富士通ユニファイドワン(UnifIDone)
- IDサーバー機能
- 教職員のデータのみ、30分に1回、各高専サーバーと機構サーバーで同期
- パスワードポリシーの統一
- 学認連携をどうしたいか(アイディア段階)
- 今後のとりくみ
- LANケーブルが古い(お金がなくて買えない)ところさえある!
- まとめ
- 各校内システムとの認証連携を随時開始
- Web給与明細システムの連携ができた
eduroam
- eduroamとは
- セキュリティー
- 安全で使いやすくて安定、WPA2/AES
- 個人認証 → インシデント時の追跡
- 強固すぎるとかえって使いにくい
- 教職員・学生で数万人規模になる大学も! → スケーラビリティー
- 教員ですべてをカバーしようと考えないことが重要
- eduroam
- eduroamの認証連携
- eduroamの参加方法
- 無線LANの運用管理
- セキュリティー
- 通信内容の暗号化: 共通鍵(WEP) or 利用者認証(主体認証、機器識別)
- 学内ネットワークの利用資格の例外措置
- 通常は「本学構成員 + 許可を受けて情報システムを利用する者」
- eduroamでは個人認証できる → 大学側でeduroamなら個別の許可不要という例外措置
- 互恵的な無償での提供(非事業)
- セキュリティー
- 代理認証システム
- 仮名アカウント発行システム: 学認が前提
- 個別ユーザが個人用アカウントを随時取得可能
- 学認システムのみで使える
- 無線LANネットワークの構成・アクセス制御
- 学内ページを見られるのがイヤだ、電子ジャーナルなどの不正利用されたらイヤだ
- ゲストネットワークの構築
- 認証VLAN利用
Q&A
JICS2013レポート(4) 3/5午前 キーノート
OpenID
- OIDF J 八木さん
- JICS
- 来場予定者数 1200名 (2日間のべ)
- 昨日は350名くらいだった?
- digital identityという単一のテーマでこれだけの人が集まるのは世界にも例を見ないconference
- OIDF Jを立ち上げたのは5年前
- ID, 属性情報の連携が広まってきた。標準化、普及活動をしてきた
- 民間ではOpenIDを使った連携はデファクトになっている
- 自民党でもマイナンバー法案が閣議決定された。「マイナンバー」は「個人番号」になるかもしれない。「マイナンバー法案」も「番号法案」となり、国会でも熱い議論がされると期待される
- 今日からは「個人番号」「番号法案」としてツイートしていただきたい
- 官民でのID連携はますます高まる
- 来場予定者数 1200名 (2日間のべ)
- 今回、NII, OIDFが共同でJISを開催
- トラック紹介
- キーノート、学認、Trust Framework Workshop、ID Tech Intro、Enterprise Sessions
Y! Japan ID Open Strategy 〜爆速 to the Future〜
- Y! 谷田さん
- 爆速Tシャツw
- Y!のオープン化について
- Y! Jの紹介ビデオ
- 利用者数4279万人、PV539億/月、日本のインターネット利用者の84%が使用
- 2012年4月から新体制になって課題解決エンジンとして活動
- Y! Jオープン化にはじまり
- トップページのほとんどのサービスでY! IDを使っていただいている
- 顧客にとってY! IDはY!に閉ざされた空間でだけ使えることはうれしいのか?
- 広告だけに使われる、というのも違う
- 2007/4 広告 ADネットワークオープン化
- 2007/8 Y! ウォレット
- 2008/1 OpenID 2.0
- 2009/7 OAuth 1.0対応
- 5年経った今 Y! J ID 2800万ID、Y! ウォレット2.3万件のパートナーサイト
- 2012/12 OpenID Connect採用 → YConnect
- OpenID Connectがもたらすもの
- 開発効率があっとう的に上がった
- 安全性があっとう的に高まった
- OpenID Connectがもたらすもの
- 開発効率アップ → パートナー様に爆速で導入
- GREE × YConnect: 2週間で実装
- CyberAgent × YConnect: 2週間
- 安全性が高まった
- 属性情報の活用
- Y!Jが預っている顧客情報をパートナーサイトに安全に持ち運ぶことが可能
- 顧客ニーズに基づいてパートナーサイトで活用
- 属性情報の活用
- Y!Jのオープン化を5年にわたって考えてきた
- IDのオープン化を進めていて思ったこと
- これまで
- 認証・認可のプロトコル自体が分離・分散されていた
- パートナーサイト: IDをたくさん採用することによって多数の顧客を集めていた
- これから
- ソーシャルのパートナー: ソーシャルに強い顧客を集める
- 決済・コマースのパートナー: 決済情報を備えた顧客のID
- パートナーが使いたいと思っている顧客のIDを集めたい : 顧客サービスに合ったIDを使いたい
- 「IdPはユーザドリブンで選択される」
- ユーザーファーストで課題解決 → インターネットをますます活性化
- Q: フェデレーションすることをビジネス的に決断するに至ったキーポイントは?
- A: 2つある
- ひとつはスマートフォンの登場。顧客のコンタクトポイントがY!トップページからアプリになった。アプリにおいてYConnectを使いたい。
- もうひとつは、技術者がアプリをどんどん開発できる環境が備った → Y!のID基盤を使ってサービスを作れるようになった。ID管理はコストがかかる。悪い人と戦うにもコストがかかる。パートナーには本業に徹していただきたい。そういう環境を提供したい
- A: 2つある
Mobage Open Platformの歴史とIdentity関連技術について
Google Identity Directions
- Tim Bray
- What does Google care about?
- 検索はGoogle活動の中心であり収入の中心でもある
- 検索アルゴリズムの開発が重要
- 10年前は検索を改良するのは楽だったった。楽な勝利はすべて終わった。低い果実は全部取っちゃった
- クエリを理解するのは難しくなっている
- 自明な方法はユーザーを理解することだ
- OAuthを検索すると、左側に人形アイコンが出る。それは「あなたが」見るべき情報だ
- Search Needs to know who you are
- 右上をクリックすればパーソナライズをon/offできる
- もうひとつはモバイルデバイス
- ソーシャル
- Internet is not about 本を買う、猫ビデオを見る
- Internet is for communicating
- 人々のポテンシャルにリーチするにはソーシャルが必要
- Social Needs to know who you are
- ID technologies
- いま感じているpainはどんどん悪くなる
- 人々が使わないといけないIDの数は増え続ける
- ID技術のリストもすでに長ーい。頭痛の種
- 複雑すぎる。難しい。エキスパートでないと理解できない。disappointing。まだ成功とはいえない
- 大きな問題はtoo hard to solve the whole problem
- Internetの歴史を見るとlightweightな技術が勝ってきた。80%のbenefitは20%のeffortから得られる
- Google is betting very heavily on OAuth2 and OpenID Connect
- Everything we do forward Search, Social, Mobile, will be based on OAuth2 and OpenID Connect
- 他の大きたtechnology providersもそうである
- 3つのこと: introduce new identity technology
- 1. Good User experience
- 2. Effective security
- 3. Good developer experience
- これまでは無視されすぎていた。500ページのマニュアルや難しい数式が必要だった。developers don't have to understand identity. 使いやすいAPIがあればいい。そうでなければ使われない
- Googleがしていること
- Account Choooser
- mobile applications
- モバイルデバイスで、誰かにパスワードをタイプさせるように頼むのはunreasonable
- 君はどれ? と選ばせるのが理にかなっている
- ほとんどのmobile appはバックエンドサーバーを持っている。ゲームでもハイスコアを保存している
- Google is committed to work with identity
- ID communityにgood-byeを言うべきだ。IDエキスパート同士で話をするのではない。世界中と話をするべきだ
- stop storing password, stop using password. Use identity
- Q&A
- natさんからコメント
- ID federationを使ったAPI連携がどんどん主流になる
- ちょっとprivacyの話が出てきた。policyトラックではそういう話もする
Developers Summit 2013レポート(3)
デブサミ2013 2/15分後半です。
5msの中身を公開！〜ネット広告配信と支える職人達〜
RealTime Biddingとは
- 1.適切な広告選定・入札額決定
- どの広告を入札するべきか
- 落札しただけではダメで、クリックして成果が必要
- いくらで入礼するべきか
- 上げる: 配信量増○、コスト高×
- 下げる: 逆
- どの広告を入札するべきか
MicroAd BLADEの特徴
- MicroAd BLADE
- 2011年6月から
- 4000社をこえる広告主
- リターゲティング/オーディエンスターゲティング広告
- retargeting
- 広告主サイトへの再来訪を促す広告配信手法
- audience targeting
- 潜在顧客をターゲットとして広告を配信する
- 統計的手法により、どういう人が興味を持っているかをためる
- 広告主はどのあたりに配信したいかターゲットを設定
- 設定に合う人に対して広告を配信
- 潜在顧客をターゲットとして広告を配信する
- BLADEのRTBレスポンス数
- 2013/1現在、25億件/日
BLADEの内部
- 処理の流れ
- 広告リストアップ
- 広告データ、リターゲティング、オーディエンスターゲティングデータ、demographicsデータ それぞれ数億件
- 配信不可広告のフィルタ: 競合社の広告など
- 入札額の導出
- frequencyデータ: 同じ広告を何度も見ると興味が下がっていくため
- 入札広告の決定
- 広告リストアップ
- 5msへの取り組み
- データ参照がボトルネックになりがち
- 一般Webアプリと同じ
- アプリケーションまわりのデータ参照の工夫
- KVS(Kyoto Tycoon)
- replication
- cache
- object cache
- データ参照がボトルネックになりがち
- KVS: Kyoto Tycoon
- replicationとローカル参照
- デー糸サイズが大きい(1k〜)と通信コストが高くなる
- データ参照するRTBサーバ上にスレーブを立てて通信を減らす
- cache
- 使い分けが大事
- 整理性やリアルタイム性をどの程度担保すべきか
- よく使う方法2つ: 全件キャッシュ、有効期限つきLRU
- 全件キャッシュ: まんべんなくアクセスされる
- 起動時にロード、2分ごとに更新スレッドで全件リロード
- 入札に選ばれたときに最終確認する
- LRU: 頻繁に参照されるもの
- 広告枠ごとのベース入札額
- 一定件数だけcache
- ミスヒット時、マスタから取得、一定確率でcache
- 使い分けが大事
- object cache
- 取得したデータをJavaのObjectにするにも時間がかかる
- Objectになった時点でキャッシュ
まとめ
- まとめ
- RTBってのがあるんだよー
- 業務ロジックの高度化と処理の高速化が両方必要
- Microad BLADEはがんばっています
- もっと話したかったこと
- 少数精鋭: 入札アプリは3名のエンジニア
- なぞな職人たち
- Action!
- 職人魂でエッジの効いたモノづくりをしていきましょう!
- 想い: 動けばいい/無駄なんて気にするな、サーバー足せばいい
- → クールじゃない。伝統職人に笑われちゃう
感想
普段見ているWeb広告がこのような仕組で配信されているとは知りませんでした。時間的制約のある中での処理の工夫が面白かったです。最終確認でアウトならあきらめるというのは、処理数が多いからできる技でもありますね。
ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜
- 15-A-7
- スライド
- @ryuzee 吉羽龍太郎 Ryuzee.com
- Microsoft MVP
- アジャイルコーチ
- SCRUM Boot Camp the book
はじめに
- 本当に必要なものがわかるか?
- ブランコの絵
- SIでよく起こる話
- もっとひどいバージョン
- 期待のマネジメントに失敗
- システムの機能の利用割合
- 2000年 Stanish
- まったく使わない機能が45%、ほとんど使わない19、たまに16、よく使う13、いつも使う7
- まったく使わない、ほとんど使わないで64%。これらを作らなかったら3分の1の期間・コストで作れたのでは?
- あなたの開発はムダだらけ?
- トヨタ生産方式
- ムダ: 作りすぎ/手待ち/運搬/加工/在庫/動作/不良をつくる
- 加工のムダの例: 進捗はわかっているのにおえらいさん向けにプレゼンを作る
- コストの見積りは正しいか
- 不確実性コーン
- ウォーターフォールV字モデル
- 時間がかかりすぎて、出来た頃には要求が変化。そもそも要件があっていなかったということが全部できてからわかる
- よく見かける光景
- 設計までは順調→開発・テストで遅れ→受入れ試験でニーズ不一致が判明
- 多くのリスクが後半になって顕在。そのころにはとり返しがつかない
- Agile Manifest
- Kent Beck, Martin Fowlerら
- 顧客満足を最優先し、規値あるソフトウェアを早く継続的に提供する
- マーケットに製品を早期に投入して、投資を回収し、利益に結びつける必要がある
- ドカーンと計画して長い時間かけて作ります、ではない
- MVPとフィードバックループ
- ビジネスの成長とプロダクトの成長
アジャイル開発
- よくある話
- 「てめーもっとちゃんとアプリ作れ」
- 「運用でなんとかすんのがあんたらの仕事だろ」
- 「そんなのどっちでもいいからビジネスのこと考えてよ」
継続的デリバリー
- 継続的デリバリーの原則
- 1. デプロイはくり返し可能であり信頼性がある
- 2. すべてを自動化する
- 3. 難解、苦痛なことを自動化
- 4. すべてをSCMで管理
- 5. 完了は「リリースされたこと」を意味する
- 6. 品質を作りこむ
- 7. すべての人にリリースプロセスに対して責任がある(もっと言うとプロダクトに対して)
- 8. 継続的に改善する
テスト自動化
- テスト自動化
- 問題は早めに解決する
- 早く見つけて早く直す
- デプロイのたびに人手でテストするなんて無理
- テストしてないものを目をつぶってデプロイしてはいけない
- 悪魔のささやき: 設定ファイル1行だけだから平気だよね?
- テストしてないものを目をつぶってデプロイしてはいけない
- アジャイルテストの4象限
- 自動テストに求められる特性
- repeatable, independent, self validation, easy
- webだと
- controllerのテストを沢出書かなきゃいけないのはfat controllerだから
- Jenkins
- 継続的にテストしていないといつこわれたかわからない
- CIサーバ
- プロジェクト初期からやる
- メトリクス取得や静的解析は初期からじゃないとダメ
- CIアンチパターン
- テストコードと製品コードを同時にコミットしない
- 帰り際にコミットして結果を見ずに帰る
- 何も変更してないのにビルドが落ちたり落ちなかったり
- CIサーバーのメッセージが多すぎる
- 本番環境とステージング環境が大幅に違う
- チェック内容が変わらない、プロセスが変わらない
- などなど
バージョン管理
- バージョン管理
- 設定情報のバージョン管理
- バージョン管理は開発者のしつけ
- どの断面でも再現可能か(昨日、1週間前、先月のバージョンに戻せるか)
- ソースだけではないDBスキーマも
環境構築の自動化
デプロイ自動化
- デプロイ自動化
- 以上ができてはじめて可能になる
- 手でWinScpとかありえない
- ゼロデプロイ
- プロジェクト最初に、デプロイを自動化する
- デプロイが自動化しやすいプロダクトの作り方がある
- 気をつけること
- デプロイが失敗した場合にロールバックできるようにする
- デプロイが途中で失敗した場合、その先を手動でやってはいけない
- Capistrano
- よくあるデプロイ方法
- 難しいところ
- DBの不可逆な変更を避けるようにアプリを作り込んだほうが良い場合が多い
- 1回冗長にしておいて、うまくいったら消す
- いったんトリガを張っておいて後で消す
- ビルドパイプライン
- テスト完了してからリリースするまで何日かかる?
- 障害時に1日でリリースできるのに、障害でないときにできないのは、プロセスに組織的なムダがあります
- ワンクリックでデプロイできたとしても、リリースの意志決定が遅かったら意味がない
- → 組織のアジリティーを高める
- 変化しないとゆるやかに死ぬ
- 自分たちで変えていく。できることは沢山あるはず
- すぐできるものではない
- DevOps
- 開発と運用が協力しあって、継続的にプロダクトを顧客に届けつづける
まとめ
- まとめ
- ビジネスのために継続的に
- アジャイルなやり方
- テストの自動化
- 常に出荷可能
- デプロイや環境構築も自動化
- 改善をずっと続ける
感想
「ワンクリックデプロイ」というタイトルから、chefやcapistranoの話かと思って聞きにきました。しかしアジャイルやスクラムの話が長々と続き、これはどうしたことだと思っていました。話が最後の方まで来てようやく、「ワンクリックデプロイ」というのはアジャイル開発の一部であることを理解しました。ばーんと導入してばーんとできるようになるものでなく、プロセスの改善を続けてだんだん近づいていくゴール(サブゴール)だということがわかっていなかったんですね。一段上の視点を得られた貴重なお話でした。
セキュリティ要求仕様モデルプランで日本は変わるか？
- 15-C-8
- @takesako
- @ockeghem 'or'1'='1'--@tokumaru.org
- うっかりSQLインジェクション脆弱性があると困るアドレス、アカウント登録には使っていない。こわくて使えないw
- orをandにすればというマジレスをもらっている
- 百瀬昌幸さん
- セキュリティ要求仕様モデルプラン知ってる人? → 6人くらい
- 時々オフレコマークがつきますよ
- 地方公共団体における〜〜モデルプラン、略して「モデルプラン」
- LASDEC (財)地方自治情報センター
モデルプランの紹介
- 百瀬さん
- スライド
- モデルプランの中身
- セキュリティー仕様選定基準イメージ
- A 実際に攻撃に使われている手法
- B 現売点で悪用可能で、将来攻撃に悪用される可能性のある手法
- その他に未知の脆弱性などがある
- 対策が可能でコストがかかりすぎないものを選んでモデルプランとした
- セキュリティー要件の提示方法: それぞれ長短あり
- 脅威を明示
- 名前を明示
- 実装方法を指定
- 検査方法を明示
- 実装方法を指定するのがわかりやすい
- 脆弱性が発見されたら直してください、など
- モデルプラン検討経緯
- 救援を送る → ムリ、首長を啓蒙する → どこから話していいか
- 根本的な対策が必要 → そもそも脆弱性のあるソフトを作らなければいい
- 容易に改修できるようにする
- 今後、地方公共団体のセキュリティーレベル向上に必要な施策
- 事後対策 + 事前対策(new) = セキュリティーレベル向上
- 地方団体が1800近くある。お金ののあるとこもないところも
- ユーザー企業・団体・国も巻き込みたい。ベンダーさんにもあらかじめ対応しておいてもらいたい
- 「いいモデルプランです、パクっていいですか」「どんどんパクってください」
- モデルプランのポイント
- 「セキュリティ保証期間」という期間を設け、「脆弱性リスト」で示したものに限定して対処を求めている
- 「セキュリティ保証期間」==5年間(稼動予定期間)とする
- 瑕疵担保期間とは別
- 追加費用なしで直せ≠無償で
- 追加費用なしでの効用
- リスクの見積もりを提案者(ベンター)に委ねる
- 「自ら開発したソフトで事後に脆弱性が発覚するリスクを見込んで保守費用に対応費用をあらかじめのせといてください」
- 地方公共団体の調達==ほとんど入札、となれば広がっていくはず
- モデルプランの採用が進むと…
- 対応可能なベンダーが強くなり、脆弱性のある製品が減る
- アンケート: モデルプランを利用したいと思いますか
- まとめ
- 期間と内容を限定して、万一出たら直してくださいね、となっている
- 熱心なベンダーにとっては優位な仕様
- 地方公共団体向けだけど、もっと活用の幅を広げたい
モデルプランの主要論点
- 徳丸さん
- 大変な仕事だった。高木浩光さんにウンと言わせるのが大変だった
- 論点1: 脆弱性名の列記ではあいまい
- 「○○脆弱性がないこと」では契約にならないのでは? など
- 論点3: セキュリティー保証期間
- OS、ミドルウエアも5年なら5年保証しないといけない(サポートライフサイクル)
- セキュリティー保証期間、これは瑕疵担保ではないのか → 別のもの
- 論点4: 地方公共団体職員の検収能力に関する課題
- 職員さんはまじめだが技術力はない。検収できるのか?
- 受注者に「セキュリティ検査報告書」の提出を求める。入礼価格の中でやってもらう
- 発注者にとってのモデルプラン
- 発注者とベンターの責任分担を明確にする
- 未知の問題については責任を問えないので、発注側の責任
- 提案者にとっての意義
- セキュリティ施策について、何をどこまでやればよいかを明示
- 対応範囲を明確にする
- 提案時に責任範囲を明確にすることにより、真面目なベンダーさんが得をするように(安かろう悪かろうが勝たないように)
- 脆弱性が指摘されたとき実際に改修しましたか?
- 1: 発注者の費用で直した 15%
- 2: 受注者の費用で直した 55%
- 3: そう方の負担で直した 30%
- 4: 直さなかった 0%
- どうせ受注者の持ち出しになるなら、そう明記しておくほうがいい
- サポートライフサイクルポリシー
Q&A
- 会場: 自治体サイトに脆弱性が発見された場合、ベンダーの立場として費用をかけて改修しましょうと言ってもなかなか難しい。enforceする仕組はあるのか
- 百: お金がなければできない。結局お金の問題になってしまう。今後はあらかじめ用意しておきましょうという話になる
- 徳: 脆弱性診断をしているとPHP4だから上げましょう → 「RedHatのサポートが切れているので上げられません」…あっ、PHPって無料じゃなかったんだ、と思った瞬間だった
- 竹: サポート期間が5年ということでRHEL6を選択するような力がかかると
- 竹: モデルプランはPHP以外にも適用可能?
- 徳: JavaもOKです。ただし、サポートサイクル的にJava6が終わっても平気かどうかは検討が必要。どうしてもJava6でないと困るという場合、重要事項説明を書いてもらって別途費用がかかる旨書けばいい
- 竹: 最近のJavaの脆弱性はクライアントアプレット側のものが多いが、サーバー側の修正も必要でしょうか
- 徳: 大丈夫という判断ができるなら、当てなくてもいい
- 竹: Javaの脆弱性で困ったことはあるか?
- 竹: Javaの場合はbyte codeの後方互換性は守られているので、気にしない人が多いのかな、と思っていたんだけど
- 徳: そこまで大胆に上げる人はいないのでは?
- 会場: オラクルから非互換リストも出ているので、テストなしでアップデートはありえない。unit testで確認するということはある
- 百: クライアントサイドの問題が取りざたされている。省庁によってはJavaの古いバージョンを使い続けるのは許さないというのが強く打ち出されてきている。そういう号令は省庁では絶対の話。クライアント側はむしろ強く求められていく
- 竹: Javaアプリを使っている地方団体アプリはあるのでしょうか
- 百: いやーあるんですよー、IE6でしか動かないとかー。対応するためにベンダー内では、専用のパソコンを別ネットに用意して検証しているようだ
- 徳: 「5年しか使えないの?」という声もあった。発注したからには未来永劫使いたい、と。5年経ったらチェックして、使えますねとなったら使い続けるなどを推奨する
- 会場: セキュリティーの範囲として、スマホ、タブレットに対応というと、Webと環境が違うと思う。適用できるのか
- 竹: JSSECから「アンドロイドアプリのセキュア設計・セキュアコーディングガイド」が出ているのでチェックするのをおすすめ
- 会場: リスク評価して応札価値に上乗せしろ、とかそんなことは実現可能なのか
- 百: 脆弱性が出たのに対応してくれないような業者は淘汰されていくと考えている。チェックできるような書類も提出してもらうことになっているので、後から何かあったときにもさかのぼってチェックできる。このモデルプランで万全ということではなく、うまくいかないということになればまた第2版、第3版と改訂していけばいいと考えている
- 会場: Javaのアップデートするとき、旧バージョンをアンインストールしないと、アプレットがバージョンを指定することができてしまう
- 百: 旧バージョンを消してね、という通知はしている
- 会場: T市のように海外のサービスに自治体サイトを移した場合、海外サービスのセキュリティー評価をするようなこともあるのか?
Action!
Developers Summit 2013レポート(2)
デブサミ2/15分前半です。長くなったので2つに分けました。
2日目は同じ会場で続けてセッションを聞く場合、廊下に出ずにチェックインできるようになっていました。ラウンジの電源も1日目の終わりから使えるようになっていましたし、スタッフのみなさんも改善が早いですね! そしてGREEさんのミネラルウォーターをいただきました。お水は本当に助かります。いつもありがとうございます。
「爆速」を支えるテクノロジー
- 15-A-1
- 村上臣 Y! チーフモバイルオフィサー
- スライド
- 漢字でわかるのはいいですね「爆速」
村上さんについて
- Y!は基本的にPCの画面が想いうかぶでしょう。CMOを設置したのは…
- 自分はPCの経験がない。ずっとモバイル畑
- 最初は社内でも肩身のせまい部門だった。回りとPVもケタが違う。いつも携帯をたくさん並べてポチポチやってる人達、みたいなカンジ
- 転機は2006年、ソフトバンクがキャリアを売収してYモバがはじまった
- アマチュア無線
- 小学校のころは自転車に無線機を乗せていた
- 大学生のころ、電脳隊
Yahoo! Japanについて
- 2012年3月1日 Y!の経営体制変更
- 創立以外増収増益をした、伸び続けている会社の役員を全部交代した。これはすごいこと
- スマホの大陸が大きい、進化スピードも速い。それに合わせた体制にする
- 経営陣も10歳以上若返り
- 爆速
- 「迷ったらワイルドに行け」
- 新社長宮坂の新入社員への言葉: 4つの約束
- Focus。やるならフォーカスしろ、1個の得意技
- Fast。早く動け
- Fun。楽しんでやれ
- Be Wild。迷ったらワイルドに行け
- 新社長宮坂の新入社員への言葉: 4つの約束
- インド進出
- Y! Inc.は世界中にブランドを持っているので、日本国外で何かやるときにはY!の名前は使えない
- Bharti、エアテルとやっている
- 米Bashoと提携
爆速について
- 爆速
- エンジニアの才能を生かす
- 1. 承認プロセス数: 8 → 2
-
- 関所が8つくらいある。ウォーターフォール的な企画審議とか
-
- 3. 月1ペースで全社ハッカソン実施
- 4. Hack Day
- 5. MYM
- Hack Day生まれのプロダクト
- コミュニケーションツール
- Node.js/MongoDB
- HTML/CSS/JavaScript
- 社内採用をYammerと競って勝利
- 働き方が変わった。「メールよりMYM」
- 趣味の部屋、秘密の部屋もたくさんある
- 内製なのでフィードバック→即改善
- 6. GitHub Enterprise全社導入
- 2012年3月末、エンジニアがほしい → 上層部が「いいね、動いてみて」
- 7月、アカウント数160でスタート → 一瞬でなくなる
- 現在アカウント数500
- Gitのすごさはpull request
- 自律的な現場への変化、活性化
感想
小学生のころから自転車で移動体通信とはすごいですね! 爆速、そのスピード感はすごいものを感じました。「エンジニアの才能を生かす」というのにしびれます。「マインドを変える」ということに関してエンジニアは柔軟であるだろうと思います。エンジニアのマインドが変わることによって、回りの人達も巻き込んでいけるんじゃないかと思っています。
モバイルファースト再考
- AKQAの紹介ムービー
- The Biggest Revolution is Happening on the Smallest Screen We Have
モバイルファースト
- モバイルファーストの時代と言うが、モバイルファーストとは何?
- モバイルファーストの時代
- 元気あるサービスはモバイルオンリーのものが多い
- Path, Square, Flipboard, Instagram, LINE
- モバイル向けのデザイン原則
- Mobile First!
- Luke Wroblewski (Y!)
- Growth, Constrain, Capability (成長性、制約、可能性)
- モバイルの成長性: まあわかってますしいいですよね
- モバイルの制約
- 小さい画面/パフォーマンス/場所と時間(モバイルではむしろ自由)
- マイナスのデザイン
- ネイティブの機能を使ってどうやるか
- 必ずしもWebデザインの話ではないはず
- モバイルの可能性 ← ここが本来のmobile firstでは?
- Mobile First
- モバイルで出来ること、出来ないこと → 特性を活かしたサービス
- Contents First?
- モバイルでもPCでも同じコンテンツを
- まずはコンテンツありきであるべき
- → 本来はデバイスに依存しない情報提供という考え方
- Future Friendly
- Mofile Firstの利点
- 閲覧環境を選ばない
- ブラウザに依存しない
- 情報構造がシンプル
- データが小さく軽い ……はず
ユーザーを見る
- モバイルを使う人ってどんな人?
- デザイン思考
- まずはプロトタイプを作って、現場で実験と検証を行い、問題点を発見→改善、をくり返す
- エスノグラフィーは本質を見抜くためには上流の手法
- 小中学校を観察した例
- TVがまったく使われない
- 連絡ボード(コルクボード)があっても黒板が使われる
- 椅子の足にテニスボールをかぶせている
- キタナイ雑巾とキレイな雑巾を彼らなりに分けているが大人にはわからない
- 新しい発見があります。本物(本筋)の発見があります
- Action!
- 書を捨てよ、町へ出よう(寺山修司)
- デスクを捨てよ、モバイルを使おう
- 本当のユーザーを知ろう
- 実際にモバイル端末を使い倒そう
- 端末は自分で買おう
- 自分で買わないと使い倒しません
- モバイル端末を使う日を週4日、少なくとも3日設定しよう
- 書を捨てよ、町へ出よう(寺山修司)
Opsから挑むDevOps
- 15-D-4
- 千葉則行さん エクシード
- インフラエンジニアとして
- Dev - DevOps <= Ops
- Action!
- 人と艱難を共にすべく、人と安楽を共にすべからず
- お題
- エンジニアを解放する
- 深夜の仕事が多い。年とってきた
- DevOps
- 2009年か2010年?
- 私たちの取り組み
- 改めて考えてみる
- 再びAction!
- エンジニアを解放する
インフラエンジニア
- インフラエンジニアの苦悩
- 突然の…
- 明日までに…
- そんなこと言われても…
- 分業〜すべてのスキルを持つことができない時代
- Dev vs Ops
- エンジニア vs 営業
- 企画部門 vs 技術部門
草勢衛基味
- 対立なんて不毛
- 世界中でスーパーな人たちが切差たくましているのに
DevOps
- コラボレーションの仕組みをつくること
- Cluture, Lean, Automation, Measurement, Sharing
- DevOpscafe.org
Culture┳Lean ━Automation
┗Sharing━Measurement
- DevOpsと言って思いうかぶのは
- Chef, puppet, cfengine
- 例えばChef
- Chef: 無防備な状態でつっこんでいくと間違いなく返り撃ちにあう
- Chefの解説
- Mcollective
- Puppet labsのブロダクト
- 去年かおととし
- スケーラビリティーがある
- MQに入れ、ノードが取りに行く
- 実際のインフラ屋の仕事
- 設計、構築: とても静的な仕事〜設定したら変えたくない
- 障害対応: とんでもなく動的〜急いで対応しないといけない
- Automation?
- 自動化できるのは静的なコトだけ
| ←静的 | 動的→ |
| Chef | Mcollective |
| Puppet | Capistrano |
- ツールのまとめ
| Pull | Chef/Puppet | ○ | 状態の一貫性 |
| × | 動的な操作は難しい(順番を指定して実行) | ||
| Push | Capistrano | ○ | 任意のタイミングで操作 |
| × | なんでもアリになってしまう | ||
| × | スケールしない | ||
| async | Mcollective | ○ | 非同期型、スケールする |
| ○ | 任意のタイミングで操作可能 | ||
| × | 単なるメッセージトランスポーターである |
こんなのはじめました
- cloudrop
- 運用の静的な部分と動的な部分をあわせ持つような仕組みを作りたい
- アーキテクチャ
Portal ┃ Restful API => Mcollective Client ┃ ActiveMQ ┏━━┻━━┓ Mcollective Mcollective Servers Servers ┃ ┃ Chef-solo Chef-solo Script Script
- pullでもpushでもなく非同期なカンジで仕事を流していく
- オペレーションの標準化
- なんでもアリにすると荒れる
- 再利用するべき → 標準化
ボトムアップに
↑ システム構築の標準化
↑ 利用パッケ必ジの規格化
↑ 作業の細分化
-
- → 品質(Q)-コスト(C)-スピード(Agility)のバランス
- ボトムアップな標準化
- タスク → パッケージ → バインダー → ライブラリ
- パッケージ: MySQLなどミドルウエアのレベル
- バインダー: 最終調整してシステムにする
- 「フレームワーク」とは、流れは提供できるがノウハウ蓄積はお客様でやってね、ということ
- 仕事はできる人に集まってくる
- シニアなエンジニアはシニアな仕事をしてほしい。どんどんクックブックを生産してもらいたい
- 現場の人は手順として確立されたものを確実に実行してほしい
- cloudropの効能: 標準化してナレッジをためると何ができるか
- 手元の環境でテスト → 本番へ
- テスト、QA、本番環境を同一に
- configureの引数変えないでください! など
- public <=> private間の相互利用
- blue green deployment
- 本番と新しいバージョンを全一構成で用意しておいて切り換えるデプロイ手法
改めて考えてみる
再びAction!
- Shareできるコト、できないコトがある。
- 「人と艱難を共にすべく、人と安楽を共にすべからず」
- つらいこと、難しいことは共有しやすい
- 楽なことを共有しようとすると堕落してしまう
- つらいコト、大変なコトを共有することから始めましょう
感想
ボトムアップからの積み上げというのは、インフラ・オペレーションの仕事にはよく合うと思います。
NoSQLの野心的な使い方 〜Apache Cassandra編〜
- NoSQLのよくある誤解
- Cassandraを選んだ理由
- どういったものを使いたいかをよく考えて選んでほしい
- 一長一短あるので検討してほしい
- NoSQLとRDBMSとの本当の関係
- 実案件でのNoSQL
- 大規模ポイント管理サービス: 視聴率データの取り込み
- 秒5000回の書き込みの実績
- 1800万回/時、130億回/月
- スマートメーター系への展開
- 拡張性の担保
- サーバーを追加すればOK
- すでに秒間16000回を実証済
- サーバー障害もひと通り経験
- HDの大規模障害(半分落ちた)にも耐えた
- こんなシステムを1人で構築することもできるのがNoSQLの面白いところ
- 大規模ポイント管理サービス: 視聴率データの取り込み
- NoSQLあるある
- 社長「NoSQLって何?」 → 「さすがですね! これからのびる技術です」
- 人事「新人でもできる?」→「ちょうど良かったです。そういう人の方が向いてます」→人材確保
- 部長「お金になるワケ?」
- NoSQLが熱い領域
- M2M(広い意味で)
- センサーネットワーク
- 業界大手はHadoopによる可視化まで
- 既存領域でもまだまだいける
- M2M(広い意味で)
- Action!
- 合言葉
- NoSQLでうでを試そう
- 大切な考え方・キーワード
感想
NoSQLにはなんでも入れられるから、モデルを先に作るより画面を考えよう、というのは、SQLに慣れた頭だと逆に難しそうです。
その他
ランチは1日目に満席で入れなかったカレー屋さんに行きました。おいしかったです。イベント会場周辺のランチ事情をどこかにまとめておきたいですね。
Developers Summit 2013レポート(1)
遅きに失した感がありますが、デブサミ2/14分のレポートです。
実はデブサミに参加したのは今回が初めてでした。 長い坂を降りて目黒雅叙園へ。 最初間違ってアルコタワーに入ってしまい、中から雅叙園へ回りました。後で聞いたところによると、エスカレーターを使って行けるルートがあるようですね。ぐぐるとすぐ見つかりました。
Webブラウザの時代は終わるのか？〜スマホアプリとHTML5の未来〜
- 14-A-1 @kazuho
- スライド
ウェブが破壊したもの
iPhoneの登場とスマホアプリ
- Apple社の戦略はOSメーカーとブラウザのつぶし合いとは違う
- アプリならではの長所を生かし、AppStoreというエコシステムを形成
- スマホへのブラウザアプリの最適化は不可能ではないとはいえ、専用にするならアプリの方が楽、クロスプラットフォームにしようと思うと互換性で苦労する
- スマホアプリ=進化したウェブアプリなのか? Webの通信を使いながら、より優れたUXを提供できる。ウェブが終わりってアプリの時代が来るのか?
ウェブ vs アプリ
哲学
- Webの基本3要素(Tim Berners-Lee)はHTML, HTTP, URI。一番重要なのはURI
- スマホアプリ=ウェブを補完する存在
- better UXでウェブをサポートするが、URIは扱わないか意識させない作り
市場
- スマホアプリ市場の規模感: 広告などと比べると小さい。日本のソーシャルゲームくらい
- すべてのウェブサイトはアプリ化するのか?
- メリットは業態によって様々。零細通販では開発費がペイできないかも
- アプリ化のデメリットももちろんある: 開発コスト、アップデート頻度低下
技術
まとめ
- スマホアプリ vs ブラウザアプリ: 対立というより相互補完の関係にある
- アプリ: UIに優れる、ブラウザ: 幅広い用途に対応
- 用途別分類: 横軸: 高度なUI←→機種非依存; 縦軸: 利用頻度としてプロットしてみる
Action!
- できないと決めつけていることはありませんか
感想
スマホアプリとブラウザアプリは相互補完の関係にあるというのは実感としてもわかります。上手な分担ができれば使い勝手はよくなりそうです。アプリとブラウザ間でログインセッションの共有がもっとスムーズにできるといいな、などと連想しました。
トランザクショントレース
パフォーマンスチューニングとは
- 要件を満たすための改善活動 → 目標がある
- 3つのアプローチ → ずらす、変える、増やす
- FAQ: 対策がわからない → 問題・原因がわかったつもりでクリアになっていないケースが多い
- クリアにできない: 解明手段がない、セキュリティー上見えない
- クリアにしたくない: メンタルな理由
パフォーマンス低下 - どうする?
トランザクショントレース技術
PurePathの仕組み
- タギングを使ってデータを識別
- 各サーバーにインストールされたエージェントがメッセージにタグをつけていく
- タグを分析サーバーに集約・分析
- 流れに付随する引数なども取ってくる
- 必要なコンテキスト情報をすべて取ることができる
- PurePathの特長
- ブラウザからDBまでを一気通慣で追跡
- 全てのトランザクションの性能を正確に測定(サンプリングではない)
- マルチベンダ・マルチプラットフォーム
デモ
チューニングのアプローチが変わる
- ログ分析 → トランザクショントレース
- 再現待ちという仕事がなくなる → すぐに分析
- 勘と経験 → 科学的、説明可能な分析
- → 標準化
Action!
- 快適なアプリケーションを通じて、快適な社会を作りましょう
Ruby 2.0
Ruby誕生
- 言語を作るのは大変。"Hello World"を動かそうとすると文字列を作らなきゃいけない。そのためには文字列オブジェクト、文字列クラス、Objectクラス、といもづる式にいろんなものが必要に。出力するにはIOオブジェクト……
- 最初のHello Worldが出るまでに半年かかっている
- 1995年12月 Version 0.95初公開
- 人にあげるたびに0.01ずつバージョンを上げていた
- 1998年の1.2以降、開発系と安定系で分かれる
- 盆と暮れに出すのが目標
- プロットすると、2.0前でサチってしまいそう
- 「これは本当に2.0にふさわしいんだろうか」という心理的ブロックがある
- 一昨年2.0を出すとアナウンス「2013年2月24日にRuby2.0を出す」
とうとうやってきた2.0
- Ruby2.0の話はこれまでずっとしてきていた
- 過去の2.0候補
- RubyConf2001 最初のRubyConf。キーノートで言及
- ここで言われていることはほとんどRuby 1.9で実現された
- 新VM → YARV ささだこういちさん Rubyバイトコード
- 新GC → 世代別GC ひやまさん 1.6→1.7 でメモリ割当てを変更したらかえって遅くなってしまった
- → 1.9ではLazy Sweepを導入。2.0ではbitmap marking
- native thread → 1.8まではgreen thread(ユーザーレベルスレッド)
- Ruby開発開始当時はマルチコアCPUもなかったし普通の人がマルチスレッド使う方が効率的という考え方はなかった
- キレイにプログラムを書けるようにスレッドを用意した
- 1.8ではthread切りかえのたびにスタックをまるごとコピー。リンクしたいネイティブライブラリがマルチスレッドだと相性が非常に悪い
- 1.9ではnative thread。すべてのライブラリの再入可能性を保証できないのでGiant Interpreter Lockを使った。IOするときはロックを外すのでOK。IO heavyなプログラムでなければ使えないと文句を言われる。JRubyはnative threadだよー、とよく自慢される
- 埋込API → 1.9では不採用。C APIについては互換性あり
現代のRuby2.0の起源
Ruby 2.0の新機能紹介
- キーワード引数
- Module#prepend
- メソッドコンビネーションの実現
- 既存のクラスの修飾
- alias_method_chain: Railsで多用
- 欠点: 名前衝突の危険、名前管理が必要、修飾のグループ化が困難
- メソッドコンビネーション: CLOS (CommonLisp Object System)から
- デフォルトで定義されているもの: before, after, around
- 正直言うとRubyにはオーバースペック
- 単純化したもの → Module#prepend
- prepend: 前につける: includeは後ろに追加、prependは前に追加
- includeは自モジュールが優先だが、prependは入れた方が優先
- 既存のメソッドをwrapし、superで呼び出す。その前後に追加の処理を記述
- Refinements: 既存クラスの拡張
- メソッドの追加、wrap
- オープンクラス: クラス再定義。mathn, jcodeで使用
- 実用するのは難しい。スコープ問題がある。クラスを再定義してしまうと、プログラムの他の部分に影響をおよぼす
- そこでRefinements
- module R内でrefine String do ... end
- using Rが有効なスコープ内でだけ、refinementsが使える
- 他の言語の試み
- Enumerable#lazy
- 関数型プログラミング?
- 関数型ワナビーとして
- メソッドチェーン (1..Float::INFINITY).map{..}.select{..}.first(3) → 動かない(途中のmap, selectがeager動作)
- 提案。遅延評価版のメソッドを作る: map_lz, select_lz (lazyが_lzになっている時点ですでになまけものだw)
- 全部を置きかえるのめんどくさい
- 遅延(lazy)を求めるものは怠惰(lazy)である
- 最初にlazyってやればいい → ナイスアイディア
- (1..Float::INFINITY).lazy.map{..}.select{..}.first(3)
- 中身はいろいろ大変
Ruby 2.0以後
感想
まつもとさん、いつも楽しそうにしゃべりますね。キーワード引数はすぐにも使いたいです。Module#prependは下手に手を出すと可読性に難が出そうですが、instrumentation的な使い方が面白くなりそうでしょうか。
RubyでiOS/Androidアプリを作るMobiRuby
mruby
MobiRuby
- 米国から日本への帰国便の中でiPhoneで動くことを確認
- What's MobiRuby
- iOS app development kit
- MITライセンス - mrubyと同じ
- Objective-Cで使える機能はすべてmrubyで書ける
- Android版も準備中
- AppStoreでmobirubyをさがせ
- Vision
- MobiRubyコードの例
- defineはほとんどObjective-C
- コード補完が効かないのが痛い
- Next Step
MobiRubyスタック
- mruby-cfunc: C言語の関数を呼ぶ。mallocも呼べる
- mruby-cocoa: Cocoaブリッジ
- CocoaはほぼすべてCから呼べるようになっている
- mruby-cfuncでたたけば何でもできる
- 速度が必要な部分などはCで書いた
- delegate, blockも使える
- キモイこともできる
- Objective-CのクラスをRubyで継承、さらにObj-Cで継承
- ひとつのメソッドだけRubyで定義
- メモリ管理方法のミスマッチ(refcount vs mark-sweep)
- 苦労して実装 → 遅い
- CocoaはほぼすべてCから呼べるようになっている
- mobiruby-common: iOS/Androidで共通にできるだろう機能
- mrubyにはrequire, loadがない(なぜならFileがないから)
- requireを作ってもらった
- mobiruby-ios: iOS用にパッケージングするためのモジュール
- ロードマップ
- Cocoa bridgeがなんとかできた。デバッグ中 ←ここまで2012年度中に
- パッケージング
- ドキュメンテーション
- Wrapped Apps
- current status
- テスト
- C側のテストはだいたいそろった
- ObjC側のテストをこれから作っていく
- Pros
- Cons
- 不安定。そもそもmrubyがまだバージョン番号もない
- class/functionsが少ない
- debugがつらいbacktraceがない
- FAQ: RubyMotionと比べてどうよ
- RubyMotion は2万円、MobiRubyは無料
- 安定性から言って、いますぐ2万円払う方がおすすめですw
- MobiRubyはMatz実装なのが大きい
- RubyMotion は2万円、MobiRubyは無料
Action!
- MobyRubyの動機: Ruby Powerを世界に
- JavaScriptでiOSアプリを作る会社にいた
- mrubyのα版をもらえるので作ってみた
- 競合はしない
- ワールドワイドのポートフォリオを作りたい
- 海外のカンファレンスでしゃべる
感想
@masuidriveさんのTLを見ていると、日々@mattn_jpさんとキャッキャウフフしながらmrubyの実装を進めている様子が伺えます。mrubyいろいろ試してみたいです。
こわくない関数型言語
- @takesako Shibuya.pm
- 中野さん 電通大 形式言語理論/定理証明支援系 @ksknac
- 上野さん 東北大 SML#
- 水島さん ユビレジ(iOS上のPOS) Scala
中野さん
- 関数型言語ってこわい?
- 「関数型言語である」と思う基準は?
- 関数が値として渡せる?
- 高階じゃないと関数型じゃない?
- 参照透過性? 副作用が隠蔽/分離されている? 型推論?
- 答: 問題が不適切です
- 「関数型」とはプログラミングスタイルである
- 言語に依存しない問題
- そもそも「関数」とは
- 数学の関数の定義と同じ。入力集合の全ての値に対して結果がひとつ定まる
- 関数でない例: 同じ値でも出力が変わってしまうもの、入力集合の一部に対して値が定義されないもの
- 関数はどれ?
- getchar(), putchar(int c), random(int p), inc(int* x)
- 答: 問題が不適切。入力集合A、出力集合Bが定義されないとわからない
- 入力は引数だけではない。出力は返り値だけではない
- 関数化する
- スライド参照
- 関数化の注意点
- f(g(x))のgを関数化する → gの入力集合が変わる → fの出力集合も
- 関数型言語?
- 入出力の集合を知らないといけないはず。どうする?
- 結局のところ定義が難しい
- 関数型プログラミングとは?
- ほとんどが関数であるような記述。非関数をできる限り小さく
- どんな言語でも書けるが、書きやすい言語は存在する
- 「関数型プログラミングが記述しやすい言語」
- 関数型のメリット
- 関数型: 便利な機能に慣れる必要がありますが理論まで理解する必要はありません
- Functional is Fun
こわくないSML#
- 上野さん
- SML# 1993年 .netより前からあるんだよ
- 2012年1.0リリース、2013年2.0
- SML#: 強い型付け、eager評価。MLファミリー。OCaml, Standard MLの仲間
- 関数型は輝かしい未来。Cとかはどろくさい現実。2つの世界は名状しがたい何かで分離されている。そこにはテクニカルな何かがある。SML#は2つの世界を結ぶ。輝かしい未来でなくどろくさい現実を指向した言語 #devsumiB
- 3Dアニメは関数: 動画(時刻 t) → 画像
- 多言語プログラミング
- 手続き的な処理はC、宣言的に書けるところはML
- pros
- MLでシステムプログラミング
- プロトタイピング
こわくないScala
- 水島さん
- こわそうなScala
- implicit conversion, implicit parameter
- 誤解1: 関数型の概念を理解する必要がある
- 誤解2: implicitなんとかを使いこなす必要がある
- スクラッチから書きときは必要ない
- 標準ライブラリを読むときに勉強すればいい
- 最初に全てを知ろうとしないことが大切
- 誤解3: 関数型なコードを書かないとたたかれる
- 誤解3: Scalazという難しいライブラリを普通に使う
- コアライブラリの作者が使っていたりする
18:39
ここでMBAが電池切れになってしまい、自分も電池切れになったのでその後のパネルが思い出せません。すみません。
Togetterをどうぞ。
感想
関数型言語は、やろうやろうと思いつつまだ勉強していません。数学の定義から関数を考える、というのが結構わかりやすい気がしました。
idcon15レポート
2月1日に行われた #idcon #15に行ってきました。
ミッドタウンタワーの大きなY!セミナールームがいっぱいになるほどの参加者でした。
idconとしては過去最大?
「Andouroid Android OSのカスタマイズによるアプリ間統合認証の実現」
- ヤフー株式会社 安藤 義裕 氏
- 35歳、SI企業でシステム開発 → 2007/9からY! Japan ID
- Andouroid: Android OSとJavaのFrameworkおよび下のCのレイヤに手を入れて作ったカスタムAndroid
- 注: 個人としてやっているものでありY!がAndroidに〜という話ではありません
- デモ
- emulatorの中にAndouroid。起動に1分くらいかかる
- ポイント: Y!のアプリを2種類使う。一方でログインすると、もう一方ではログインする必要がない
- 最初にY!メールアプリを起動 → ログインしていないのでログイン画面が出る
- 次にY!ブラウザを起動。ブラウザからメールを開く → やっぱりログインしていない
- ここでログインしてY!メールを見てみる
- ここでY!ブラウザを起動
- さっきログインしていなかったY!メールを起動すると…… → ログイン済
- おまけ: ほぼすべてのアプリをY!版で置きかえてみた。検索もY!
- デモのポイント
- アプリ自体には手を加えていない
- しくみ
- ストレージの説明の前に…
- あんどうろいどではyahoo(UID/GID)を追加した
- 認証情報の共有
- データ共有の方法はいろいろある(Shared Preference, SQLiteなど)
- Shared ID: アプリ署名の証明書が同一であれば複数のアプリにも同じUIDを振ることができる
- なぜカスタマイズしたのか
- アプリ単体でデータを持つ or 広くどのアプリからでもアクセスできるデータにするか
- 今回の要望: Y!アプリに限って認証情報を共有したい
- → グループの追加のようなやり方がよかった
- データ共有の方法はいろいろある(Shared Preference, SQLiteなど)
- デバイス時代のID
- OpenID Phoneなんて良さげ
- Q&A
アプリ間のトークン共有は発行者の認証や不正な共有を考えるとOSのサポートが必要なのだろうと思いました。そのへん、OSを押さえていると強いですね。
(19:32)
「Yahoo! JAPANのOAuth/OpenIDに代わる新しい認証認可機能 〜YConnect〜」
- ヤフー株式会社 河内 俊介 氏
- こうち しゅんすけ
- ID決済本部 2008年入社 2011年〜認証/セキュリティー等ID関連
- YConnectとは
- OAuth2.0に準拠、OpenID Connectをサポート
- Y! J IDでログイン可能
- 一部属性情報の連携も可能
- OAuth 1.0と比べてRPの作り方がカンタン
- YConnect歴史
- 2011年末、設計開始
- 2012年9月中旬 → パートナー企業に提供
- 2012/11/17公開
- サポート範囲
- OAuth2.0: Authorization code, Implicit, resource owner password credential
- resource id credential: 社内のみ
- OpenID Connect: Basic Client, Implicit Client
- OAuth2.0: Authorization code, Implicit, resource owner password credential
- パートナー、社内アプリで導入
- Y!ショッピング、Y!バザールなど
- ユースケース
- Y! J IDでログイン → 認証機能を使用
- リソースの提供 → Y!ウォレットの導入 → 決済(ID連携と独立して可能)
- 属性情報の連携 → ユーザー登録時にプリセット。生年など
- 提携パートナーにはより詳細な属性
- Y!提供APIの活用
- 導入構成図の事例
- 裏話
- 機能拡張
- PPID
- OTP(one time password)
- シングルログアウト
- IDの質向上: 連携強化(自治体/金融をターゲットに)
- OpenID Connect → 爆速で追っていきます!
- Q&A
- Q: (asyoulike007) implicitはスマートフォンでwebだけ? → アプリも
- Q: 導入事例のなかでここが良かったは?
- id_tokenは特に便利という話は聞かないが…
- access_tokenによるなんちゃって認証だったのが、ちゃんと認証できるようになった
- 属性情報が信頼できるのはメリットとなっている
- Q: カスタムURLスキームで後勝ち/先勝ちの問題はどう考えているか
- Y!アプリのスキームでは外のアプリとカブらないようにしている → 外にもらさない
- バレちゃって真似されないということ? → Androidではユーザーが選択できる。真似される件は今後の課題
- 外部のアプリではカブってしまう場合がある → 懸念が残る
- Y!アプリのスキームでは外のアプリとカブらないようにしている → 外にもらさない
- Q: 提携パートナーに属性を多く提供というのはclient_idで区別? → そのとおり
実際に運用されているというYConnectだけに裏話が面白かったです。
(20:00)
「C向けサービスで2要素認証を普及させるためにできること」
- 株式会社ミクシィ 伊東 諒 氏
- 去年話題になったネタ
- パスワード管理
- ログイン画面のURL
- 2要素認証 ← 今日の話題
- C向けだとID+passwordからの脱却は難しい。2要素認証でがんばっている
- 現状と課題
- 金融系、ゲームなどでは以前から昔及
- ユーザー数の多いサービス、メールプロバイダ: パスワード使い回しが問題
- 実装方法: ワンタイムパスワード: メール/SMSで送信など
- ID/PW認証 + α
- ハードウエアトークン → コスト高; ソフトウエアトークン → 鍵; 時計がずれたら? など
- 脆弱性や課題については黙認状態
- 銀行の乱数表がごっそり抜かれる時代なのだが
- 2要素認証: ユーザーは各サービスごとに登録
- よく聞かれるつぶやき: 「○○も2要素認証対応してほしい」
- 普及への課題
- 解決案
- OpenID Providerは何をやるべき?
- RPがやるべきこと
- 自分達のサービスに必要な認証強度を意識する
- 適切なタイミング・強度で再認証を要求する
- 銀行の例: ID/PWで残高見れる; 送金には乱数表が必要
- 残る課題
- 追加認証に特化した認証プロバイダは面白いのではないか
- どうやってもうけるかはまだわからないけど
- RP側が既存OPとの組み合わせを使う → 柔軟な実装が可能
- trustが重要
- B向けに実績のあるサービスがC向けに出てきてくれるとうれしい
- 物理デバイス、生体認証などの可能性
- ID/PWの代替としては難しいが、オプションとしては使い途があるのでは?
- まとめ
- 普及のカギ: 「めんどくさい」
- OpenID Connectは重要(OPの集約など)
- 追加認証に特化した認証Pも面白い
- 作ってみた!
- id厨であれば年に1〜2個IdP作れるよね
- https://2ndauth.openidconnect.info
- メアドで登録、OTP認証のみ実装、OpenID Connect OP
- 作ってみてわかったこと
- #idcon miniやるよー
- 少人数、USTなし
- アンカンファレンスもどき
- 技術屋が気になることをじっくりと話せる場
追加認証プロバイダは面白そうですね。クレデンシャルで独自性も出せそうです
(20:25)
パネルディスカッション「スマデバ時代ぼくらは幾つパスワードを使うのか 」Ustなしの予定
- "SSL/PKIはなぜ危機に陥ったのか"
- "二要素認証やバイオメトリクスは流行るのか"
- "僕らは10年後いくつのパスワードを使い分けてるのか"
- "スマデバで普通に使えるアクセス管理へ向けた課題を展望する"
- モデレータ: ヤフー株式会社 セントラルサービスカンパニー 技術調査室 室長 楠 正憲 氏
- 米国・OpenID Foundation 理事長 崎村 夏彦 氏
- 独立行政法人 情報処理推進機構 神田 雅透 氏
- セコム株式会社 IS研究所 松本 泰 氏
- OpenID Foundation Japan 事務局長代行 高橋 伸和 氏
- 諸注意
- このパネルはustしてません
- ふつうのしゃべってることはつぶやいてもOK
- 「オフレコ」部分はブログに書いたりつぶやいたりしないでね
- 楠さん: パスワードっていつからあったのか
- オープンデータのアイディア募集 IDEABOX
- OpenIDの出現により、MS Passportが全部持っていく、ということにはならなかった
- とはいえ、いまでもいつまでもたくさんのパスワードを覚えていないといけない
- 10個以上パスワードを覚えられる人はいないだろうが、それでネット生活は心もとない
- 去年のIIWではFederated IDに対して批判的な議論もあった
- 心配: 「UX too hard」ID/PWだけでもこれだけ複雑なのにOTPとかみんな使えるのか
- PKI基盤が2011年くらいからキワドイ状況。守り続けていけるのか
- 神田さん: SSL/PKIはなぜ危機におちいったのか
- 「PKI Day 2012」から資料を取ってください
- ネットの信頼性ってどう担保されてるの
- 技術/制度・運用/実装/ユーザリテラシ ← この4つのどこでも狙われるよ
- ルートCAはPKIのTrust Anchor
- 悪い人が何をしたいか: ルートCAに保証された中間CAになりたい
- 公開鍵証明書が悪用されるのってどんな時?
- Diginotarのケース
- なぜ1か月も放置されたのか
- (オフレコにつき割愛)
- 楠: 20年も経ったら暗号なんて解けるよってわかっていたんじゃないの?
- 高橋さん: 黎明期、cyber trust japan立ち上げ → verisignフェロー
- (オフレコにつき割愛)
- 松本さん: idconは初めて。神田さんも。away感ある
- ここ2〜3年、認証局の証明書が狙われている。昔からあったんだろうけど、顕著化している
- trust anchorとして広く根づいているので、そこを取ればいろいろできるから
- いま一番あぶないのはコード署名
- ビジネスの話がわからないとわからない。証明局はもうかる商売じゃない。その中でweb for trust CAという「一見カッコイイ枠組」ができた。機能してるかというと……?
- 競合やstakeholderが多数いる中でやっていくので難しい
- (オフレコにつき割愛)
- 楠: デバイスのレイヤーが安全じゃないとダメ。もうひとつはwebが頼られてきた中で起こった事件ではないか。この先federationとかなるとwebがますます重要になるのだが
- 崎村さん: OAuth2ってsecurity propertyが全面的にSSLに頼っている。ここをちゃんとやってくれないと世界が崩壊する
- アプリレベルで暗号・署名という防波堤もあるが、やってくれる人はほとんどいない
- インフラとしてのPKIにはもっとがんばってもらいたい
- 人の話はすごく難しい。海外の電子政府でデンマークが注目されている
- デンマーク: ソフトウエア証明書を使っていたがやめた ← ユーザーPCがマルウエアだらけで、そこで署名されたものが信用できない
- 技術・運用・実装・人をバランスよくやるのは難しい
- 楠さん: web trustが主犯じゃね?の話
- イランの不正証明書がわかったのはGoogleが証明書を集めていたから。集中モデルだったから判明したことはアンビバレントである
- ユーザーを信じて何でもできる時代 → スマートデバイスでは証明書・コードサイニングによりユーザーがしたいことを保証する時代
- 集中と分散、経済的な要因が大きいと感じる
- 神田さん: 矛盾ある状況でより安全な世界を作るには?
- 高橋さん: リテラシーが事業者やユーザーにあって、みんなでPKIを使いましょうという夢があった → ムリゲー → だったらID/PW使い続けましょう
- 個人的にはID/PWはなくならないと思っている
- 限界は: ぼくは1password使っているが100個以上入っている。もうムリ。
- これを減らすためにはfederationしていかなきゃいけない
- 楠さん: 最後にみなさんからひと言ずついただきたい。100〜200個のパスワードをどう集約するかというとIdP, OPをどう集約するかという話になる。またcredentialとしてパスワードの代替となるものは何か
- 松本さん: 独占と分散という話ではエコシステムでtrustが形成されるのは重要。それが安全かというところに問題があった
- セキュアなストレージが必要。iPhoneやiPadには元々チップが入っている。それを活用して切りくずすことができそう
- 崎村さん: webではsecure storageをブラウザからJSで使えるようにしようという動きがある
- 神田さん: パスワードマネージャを頼ってはいるが、アプリの作りによって何が起こっているかは実はわからない
- 2048bitの証明書がいくつか破れている。素因数分解ができちゃった。乱数生成器の性能が悪かった。そういうことが起こっている
- アプリがやってくれないかなという話と、それがちゃんと動いていることの認証制度がほしいなあ
- 楠さん: 退出のルールというのは、退出させられて泣く人が出てくるということでもある
(21:30)
導入部楠先生の歴史のお話、毎度とても面白いです。そしてオフレコの部分の話題は本当に興味深く聞きました。
パスワードはなくならないですね…。一昔前はパスワードをコピペさせないのがセキュリティーだというときもあったと思いますが、今はパスワードをコピペできないと逆にセキュアなパスワードを使いにくいです(auto typeがありますが)。パスワードを入力させると、必ず「パスワードを忘れたときはこちら」も作らないといけないのが大変です…。
この後の懇親会にも参加させていただきました。抽選会では秋田の猫が1発目に来るとふんだのですが2発目でしたねー。惜しかった。
(記述が誤っている/発言意図と違うなどありましたらご指摘いただければ幸いです)
