最強チームを作る方法の読書感想文
最強チームを作る方法を読んだので要約と感想書きます
本書に登場するのは、Google、デザイン企業IDEO、ピクサー、アメリカ海軍ネイビーシールズ、全米プロバスケットボールのサンアントニオ・スパーズなど、高度なチームワークを誇る集団だ。 チームワークは魔法ではない。効果的な協調と協力は、3つのカギとなるスキルから生まれる。このスキルを身につければ、多様なメンバーで構成されたチームが、共通の目標に向かって一致団結することができる。 著者のダニエル・コイルは、前述のプロ集団に加え、ネット通販のザッポスから、コメディ集団のアップライト・シチズンズ・ブリゲード、さらには悪名高い宝石泥棒集団まで、幅広いチームの実例を分析し、そこから具体的な戦略を導き出した。この戦略を活用すれば、チームの学びを促し、協力と信頼の基礎を築き、前向きな変化を起こすことができる。 本書に登場するのは成功例だけではない。ためになる失敗例からは、具体的な「してはいけないこと」、よくある失敗の対処法、そして雰囲気の悪いチームを生まれ変わらせる方法を学べる。 最先端の科学、世界クラスのリーダーたちが知っている現場の知恵、そして行動のための具体的なアドバイスが詰まった本書は、最強のチームワークへのロードマップだ。そこではイノベーションが花開き、問題は解決され、つねに期待を超える結果を出すことができる。 チームの文化は、メンバーが「誰」であるかで決まるのではない。メンバーが「何」をするかで決まる。本書を読めば、あなたは最強のチームをつくる力を手に入れることができる。 チームの大きさは関係ない。チームが目指す目標の大きさも関係ない。単なる個人の集まりが、化学反応を起こして最強のチームになり、固い結束力によって偉大なことを達成する。 その方法を、あなたはこの本から学ぶことができる。 amzonの宣伝文より
ざっくり要約
パフォーマンスの高いチームはメンバーの帰属意識と心理的安全性が高い
その状態を実現するために、リーダーは積極的にメンバーへの信頼と自分自身の弱さを発信していくことが重要である
また、チーム内で目的意識が高く保たれている状態を作り出すことで、 実現したいvisionが共有できていることによりチームのパフォーマンスが上がりやすい
visionを言語化し、キャッチフレーズのようにして普段の業務内ですりこむことが効果的
感想
基本的には弱さの共有にフォーカスされていた印象を受けた
自分が目立ちたい、価値あることをしたいという気持ちを抑えてチームで成果を出すというマインドをリーダー含めチームメンバーが持っていることが大切
まあ言われればそうだよねって感じだけど具体例を交えながらどうすればそのような理想的なチームの状態を作り出せるのかが書いてある
あとこれは読み方の話だけどこういうビジネス書系は目次と最後の数段落読むだけで割と言いたいことは伝わってくるなと思った
後半は具体例はスキップしたけど結構理解できたと思ってる
こういうGoogleとか出てくる組織づくりの本とか読んでるとうちの会社はかなりこういうのを参考にして、実際の会社運営に落とし込んでるんだなあと思う
OAuth徹底入門の読書感想文 -15章-
OAuth徹底入門を読んだので感想と概要を書いていきます
今日は15章についてです
16章はまとめなので長々と書いてきたOAuth徹底入門の読書感想文もこれでラストです！！
Bearerトークンの次に来るもの
Bearerトークン以上のものが必要な理由
Bearerトークンは圧倒的に使われているトークンの種類であり、使いやす胃だけでなく標準の使用で定義されている唯一のトークン
しかしBearerトークンはリソースに提示するだけで認可されたことを意味するトークンであり、ある意味対象のリソースに対してクライアントに発行される単なるパスワードにすぎない
Bearerトークンを使わない方法としては、所有証明 (Proof of Possession: PoP)トークンを使う方法と、TLS (Transport Layer Security)トークン・バインディングと呼ばれる方法がある
PoPトークン
PoPトークンはトークン自体がシークレットになるのではなく、トークンと鍵の2つの要素で構成されている
認可サーバーはアクセストークン発行時に鍵も発行しクライアントに渡す、そして公開鍵のみ保存しておく
リソースサーバーは公開鍵を認可サーバーへ問い合わせて取得することで署名を確認する
TLSトークン・バインディング
トークン・バインディングはTLSからの情報をHTTPのようなアプリケーション層のプロトコルやOAuthのようなHTTP上で運用されているプロトコルの内部で使えるようにするための方法
HTTPクライアントはHTTPサーバーとのTLS接続を構築する際に、公開鍵 (トークン・バインディングの接続子)をHTTTPヘッダに含め、関連する秘密鍵を保持していることを証明する
クライアントはサーバーに接続する際に秘密鍵を使って署名し、ヘッダーに含める
サーバーは署名を検証し、クライアントが元の鍵ペアを提示したクライアントと同じであることを確認する
チャネルが1つの場合は上記のやり取りのみで済むが、OAuthでは通常5つ程度のTLSチャネルが必要となる
その場合は一つの接続の識別子を別の接続に送ることをクライアントに選択できるようにすることでトークンとの関連づけを扱い、別々の接続をつなげていく
感想
読み進めながらBearerトークンと提示する部分だけセキュリティ甘い感じがしていたが、やっぱり課題感を感じて別の取り組みを行なっている人がいるんだなと思った
PoPは割と手軽に導入できそう
全体の感想
かなり読み応えのある本だった
後半難しい部分もあったが網羅的にOAuth2.0についての知識をつけるにはとても良い本だと思う
著者も述べているようにOAuthのライブラリの使い方に関するガイドではなく、OAuthについて詳しくなり、どんなプラットフォーム上でもOAuthを使えるようになることを目的とした本なのでそういう全体的な知識を得たいと思ってる人にはおすすめ
完璧に理解できたわけではないのであとは困った時にOAuthとは？というのを思い出すために戻ってきて読みたいと思う
OAuth徹底入門の読書感想文 -14章-
OAuth徹底入門を読んだので感想と概要を書いていきます
13章についてはは昨日書きました
今日は14章についてです
OAuth2.0を使うプロトコルとプロファイル
UMA (User Managed Access)
UMAはOAuth2.0上に構築されたプロトコルであり、リソース所有者が別のユーザーのクライアントアプリケーションに所有者の代わりとして振舞うことを認可することができる
UMAでの各やりとりは以下のように行われる
リソース所有者がリソースサーバーを認可サーバーに登録する
リソースサーバーが認可サーバーの情報を検出し、自信をOAuthクライアントとして登録する
リソース所有者がリソースサーバーを (OAuthクライアントとして)認可する、リソースサーバーは保護APIトークンを取得する
リソースサーバーは、リソースセットと呼ばれるリソース所有者の代理として保護しているリソースの情報を認可サーバーに登録する
リソース所有者はリソースセットに関わるポリシーを認可サーバーに登録する
アクセス要求者 (リソース所有者ではないユーザー)はクライアントにリソースサーバーへアクセスするように支持する
クライアントは保護対象リソースにアクセスする
リソースサーバーは要求されたアクセス権を表す許可チケットを認可サーバーにリクエストする
リソースサーバーは許可チケットを認可サーバーへのURLとともにクライアントへ返す
クライアントは認可サーバーの情報を検出し、登録する
クライアントはアクセストークン取得のための許可チケットを認可サーバーに提示する
HEART (HEAlth Relationship Trust)
OAuth、OpenID Connect、UMAを元に策定された医療分野における相互運用性とセキュリティを高めることを目的とした標準
指針を決めておくことでクライアントが特別なことをせずとも、別のベンダーの認可サーバーと連携したり、そのまた別のベンダーの保護対象リソースと連携したりが簡単に行えるようになる
iGov (internationaal Government assurance)
行政機関のシステムで使うプロファイルの定義を行おうとしているワーキンググループ
まだ策定中の段階だが行政機関のアイデンティティシステムに関することを定義していくため大きな影響を及ぼす可能性がある
感想
UMAもなかなか難しい、、
一つ一つのやりとりは細かく解説されていたのでわかったが実際に自分が利用できるかと言われるとあまり自信はない
医療出身としてはHEARTの取り組みはとても良いと思うし、日本でも各医療データへのインターフェースが統一されてどこにいても同等のクオリティの医療が提供されるようになるといいと思う
OAuth徹底入門の読書感想文 -13章-
OAuth徹底入門を読んだので感想と概要を書いていきます
12章については先日書きました
今回は13章についてです
OAuth2.0を使ったユーザー認証
OAuth2.0は認可プロトコルであり、認証プロトコルではない
認証とは本人性の確認であり、webアプリケーションで言えば現在操作しているユーザーが誰なのかを検証することである
認可とは権限の確認であり、現在操作しているユーザーに対して許可されているアクションは何なのかを検証することである
OAuth2.0をユーザー認証を行う場合、OpenID Connectと呼ばれる方法がよく用いられる
OpenID Connect
OpenID Connectではアクセストークンの他に、IDトークンと呼ばれるトークンを利用する
IDトークンは署名つきJWT (JSON Web Token)であり、リライング・パーティーによって解析される
IDトークンは認証のやりとりで使用するクレーム (iss: トークンの発行者、sub: トークンの対象者、aud: トークンの受け手、exp: トークンの有効期限、iat: トークンが発行された時のタイムスタンプ)が含まれている
また、現在のユーザーに関する属性情報をクライアントが取得しようとした時のために、保護対象リソースはUserinfoエンドポイントを実装している
クライアントはこのエンドポイントにリクエストを送信することで、現在のユーザーについてのクレームを持ったJSONオブジェクトを受け取ることができる
感想
自分でもOpenID Connectについてしっかり理解できたわけではないので、ぼやっとしたまとめになってしまった
OAuth徹底入門の読書感想文 -12章-
OAuth徹底入門を読んだので感想と概要を書いていきます
11章については先日書きました
今回は12章についてです
動的クライアント登録
OAuthにおいて、クライアントは一般的にクライアント識別子で認可サーバーに識別される
クライアントはOAuthの動的クライアント登録によって自身のクライアント識別子 (ID)とシークレットを取得する
実行時におけるクライアント登録
動的クライアント登録では、クライアントが認可サーバーのクライアント登録エンドポイントへPOSTによるリクエストを送信する
このデータにはクライアントの表示名、リダイレクトURI、スコープ等が含まれる
POST /client-register HTTP/1.1
{
"client_name": "Client",
"redirect_uris": ["https://foobar.com/callback"],
"grant_types": ["authorization_code"],
"scope": "foo bar"
}
リクエストが成功すると、認可サーバーは新しいクライアントIDとクライアントシークレットを作成しクライアントへ送信する
こうすることでクライアントは今後の認可サーバーとのやりとりで自身のIDとシークレットを使用できるようになる
動的に登録されたクライアントの管理
クライアント表示名が変わったり、リダイレクトURIを追加したり、スコープを変更する場合、クライアントは認可サーバーにそれを伝える必要がある
OAuthの動的クライアント登録の管理プロトコルでは、動的クライアント登録を拡張したRESTfulなプロトコルを定義している
登録プロトコルの「create」メソッドと関連して「read「update「delete」メソッドを追加することで、全体的なライフサイクル管理が行われている
感想
インストール型のネイティブアプリではクライアントIDとクライアントシークレットをあらかじめ決めておくことができないというのがこれまでの章で書かれていたが、動的クライアント登録でそれを解決する方法が細かく書いてあってスッキリした
実際、サービス (クライアント)をリリースした時からサービスの情報が変わらないなんてことは特にwebサービスではありえないだろうから動的クライアント登録は重要
Amazon SNS vs Amazon SQS
社内で通知機能を実装する際にAmazon SNSとAmazon SQSどっちがいいかという議題が上がったんですがよくわかってなかったので調べました
tl;dr
名前は似てるがそもそもやってることが全然違う
Amazon SNSは pub/sub メッセージングの機能を提供するサービス。複数のエンドポイントに同時にメッセージを送ることができ、エンドポイントもウェブサーバー、Lambdaなどに対応し、Amazon SQSにもメッセージを送ることができる
Amazon SQSは キューイングサービス。メッセージをSQSにenqueueし、単一のレシーバーがdequeueする。メッセージをpushすることはできないし、複数のレシーバーが同じメッセージを受け取ることもできない
Amazon SNS
フルマネージドのpub/subメッセージングサービス
pub/subメッセージングについては以前書きました
publisher (メッセージを送る側)はEC2だろうがRDSだろうがLamdbaだろうが何のサービスであってもAmazon SNSのトピックにメッセージをpublishします
Amazon SNSは、トピックをsubscribeしているsubscriber (メッセージを受け取る側)へメッセージを送信します
subscriberには個人のサーバーやLambda、Amazon SQSなどを使用することができます
Amazon SQS
フルマネージドのメッセージキューイングサービス
サービス間でのメッセージの送信、保存、受信ができます
一方のサービスでメッセージをAmazon SQSへ送信する
もう一方のサービスがAmazon SQSからメッセージを取り出す、と行った方法でメッセージを送信する
使い分けは？
pub/subメッセージングの良いところは、publisherとsubscriberが多対多でもメッセージの送信が簡単にできることだと思います
なので送りたいメッセージの受け手のサービスが複数なのか、それとも１つなのかである程度判断できるかなといった印象です (個人の意見です)
OAuth徹底入門の読書感想文 -11章-
OAuth徹底入門を読んだので感想と概要を書いていきます
10章については先日書きました
今回は11章についてです
11章 OAuthトークン
OAuthトークンとは
OAuthのトランザクションの中核となるもの
認可サーバーはトークンをクライアントに渡す際に権限委譲とトークンに紐づいたクライアントへの許可を管理し、
保護対象リソースはクライアントから渡されたトークンに付与された権限とクライアントの要求している権限が一致するかを検証する
認可サーバーと保護対象リソースでDBを共有できない場合、トークン内部にスコープなどの情報をもつという方法と、認可サーバーがAPIを提供する方法がある
トークン内部に情報を持つ方法
JWT (JSON Web Token)
JWTと呼ばれるフォーマットは、トークンとともに送られる必要がある情報を運搬するためのシンプルな方法を提供している
ヘッダーと、JWTクレームと呼ばれるアプリケーション間で使えるフィールドに格納された情報をBase64エンコードしてトークンとして渡すことで、トークンの中に情報を保持できるようになる
JOSE (JSON Object Signing and Encryption)
JWTのままだと誰でもdecodeして情報を書き換えることができる
JWTに署名や暗号化を行なってセキュアにしたものがJOSEである
認可サーバーがAPIを提供する方法
トークン・インストロペクション
トークン・インストロペクションに関するプロトコルでは、保護対象リソースが認可サーバーに対してトークンの状態について能動的に検索するための仕組みが定義されている
保護対象リソースは認可サーバーのトークン・インストロペクション・エンドポイントにPOSTでリクエストを送り、トークンに紐付くクライアントやスコープの情報を受け取る
また、トークンをクライアントが取り消せるようにトークン取り消しエンドポイントが実装されていることもある
感想
JWTやらJOSEやら出てきてトークンの中身って見れちゃいけないんじゃなかったけ？と最初は思ったが、認可サーバーと保護対象リソースがDB共有してないケースは容易に想像できるので割と使われている仕組みなんだろう
