目的、モチベーション今まではググりながら雰囲気でシェルスクリプトを書いていて、最近業務で使うことが増えてきて、シェル使いになりたいと思ったから。一通りの文法がまとまっていたので、この1冊を理解すれば、ソースコードもガンガン読んでいけるレベルにはなると思う。リダイレクトとかは特に雰囲気で使っていたレベルだったので、ちゃんと理解できてよかった。/dev/nullの意味もわかったので、これからはガンガン使おうと思う。サブシェルで実行する。現在の環境を変えずに実行したい場合などに便利。現在のシェルで実行する。コマンドの結果をひとまとめにしたい場合などに便利。変数を明示的に使うには、{}で囲む。ダブルクォートで括ると、一つの文字列として扱われる。ダブルクォートで括ると、それぞれが文字列として扱われる。関数をカレントシェルで利用すること通常、シェルスクリプトに含まれるコマンドはそのシェルスクリプト内で動作し、起動したシェル上で動くわけではない。.という組み込み関数を使用する。ヌルコマンド(:)何もしないが、いつも成功を返すコマンド。evalコマンド複数の変換処理を一度に実行。exportコマンド引数に指定した変数を、他のコマンドやシェルからも利用できるようにする。readコマンドキーボードからの入力を変数にセットする。readonlyコマンド変数を書き換え不可にする。typeコマンドコマンドの取り扱いを表示。umaskコマンドファイル生成時にどういうモードで作るかを決めれる。ファイルの場合は666からumaskで指定した数字を指定したものができる。デフォルト値は022なので、644のファイルができる。waitコマンド引数に渡したプロセスIDのプロセスが終了するまで待つ。リダイレクトリダイレクトとは、通常はキーボードからの入力を端末に出力するが、その入力元や出力先を変えること。execコマンドとリダイレクションexecコマンドは、現在のシェルのプロセスをそのまま置き換えて新しいコマンドを実行させる。ユーザ名の取得USERやLOGNAMEという環境変数でも取得できるが、書き換えられるので信用はできない。もとのままスーパーユーザのみで実行させたい場合は、ユーザidで判断する。シグナルの処理プロセスはシグナルを受け取ると実行を中止する。trapコマンドを使う。キーボードからの割り込みで中断させるためのキー。プロセスを強制終了させる。trap等でも捕まえることはできない。アプリケーションを終了させるときに用いられる。`/`のデリミータは任意の文字列でも大丈夫。ベルリンでエンジニアとして働く」に参加してきたTweetconnpass.com目的、モチベーション海外で働きたいと思っていて、Twitterで拝見していたベルリンで働いてる方のお話を聞きたかった。ベルリンは、ビザ取得のハードルが比較的低そうで、技術レベルが高そうで待遇も良ければ働いてみたいなという温度感だった。感想ベルリンでエンジニアとして実際に働くために必要な情報が広範に網羅されていて参考になった。ビザの取得のしやすさばかりに気を取られていたが、実際に住んでみる上での話はあまり調べられてなかったので、面白かった。働く上でドイツ語はあまり必要ないとの話は聞いていたが、レイオフされたときに補償を受けるためなどで役所の手続きではドイツ語が必要になるなど、考えれば当たり前のことかもしれないが想像できていなかった。エンジニアの人気都市の比較の紹介もあり、「海外で働ければどこでもいいや」ぐらいの温度感だったので、考えが甘かったなと思ったwベルリンに住んで週末はLCCでヨーロッパに出かけてる方がいると聞いて、以前は海外移住をハードルが高いものに思っていたが、1,2年だけ旅行気分で働くのもアリなのかなと思えた。私は独身で身軽なので、英語と覚悟さえあれば、ベルリンで働けそうだと思った。悪意はないですが、ビザ情報等は必ずしも正確とは限らないので、一次情報を必ず参照してください。移民政策の影響らしい。普通の学生は多いが、働きながら通う人は聞いたことない。目的、モチベーションバックエンドのパフォーマンス改善の知識を深めるため。広範にかつ様々なレイヤーでトピックがあり、バックエンド側に限らずネットワーク全般をカバーしていた。WebRTCなどのプロトコルや、モバイルデバイスを含むクライアント側のネットワークの種類の説明などが紹介されていた。所謂バックエンドのサーバ改善だけを目的に読むのは微妙だが、トータルでパフォーマンス改善して、ユーザ体験を向上するためなら、網羅的に紹介されていてよかったと思う。初版が2014年5月で少し古いので、HTTP2の説明は他の本を参考にした方が良さそう。今回はマイクロサービスにおけるバックエンドに関連の多かったI部しかまとめてないです。メッセージが送信元から宛先まで移動するためにかかる時間。距離を信号の伝搬速度で割ったもの。パケットの全ビットをリンクに載せるまでにかかる時間。パケット長とリンクのデータ転送速度の関数。パケットヘッダの処理、ビットレベルのエラー検知、パケットの宛先決定にかかる時間。パケットが処理できる状態になる前にキューで待機する時間。当然だが、通信速度は光の速さが最大となる。光は地球を1秒間で約7周半できるため十分高速だと思われがちだが、実際の通信で何回か往復するため数秒になり、ユーザとしては不十分な速度となる。そのため、CDNなどを利用してできるだけ物理的な距離を短くするか、圧縮などでデータ量を減らすことが重要。3ウェイハンドシェイクTCP接続を開始する際に、3ウェイハンドシェイクを行う。クライアントは無作為にシーケンス番号xを選び、SYNパケットを送信。他のTCPフラグやオプションが含まれていることもある。サーバはxに1を加えてその値を確認応答番号とする。自信のシーケンス番号yを無作為に選び、自身のフラグとオプションを付加した上でレスポンスを送信する。クライアントはxとyの両方に1を足し、xをシーケンス番号、yを確認応答番号としたACKパケットを送信してハンドシェイクを完了する。これは数十msかかりコストが高いため、TCPコネクションの再利用の最適化が重要になる。受信側が処理できないほどの大量のデータを送信しないように、受信ウィンドウサイズ(rwnd)でバッファサイズを指定できる。スロースタートクライアントとサーバ間のネットワークの利用状況に応じて、通信量をコントロールした方が効率的に利用できる。ネットワークの状態は絶えず変化し、接続時には利用状況がわからないため、徐々にウインドウサイズを大きくしていくことで、解決する。輻輳ウインドウサイズは、指数関数的に増加させていく。そのため、TCP接続を再利用しない場合は、スロースタートしながら処理を開始するために、レイテンシーは大きくなる。輻輳回避パケットロスが発生したときに、セグメントを倍数的に減少させる。TLSハンドシェイク下記のような流れで、TLSによる接続を確立する。Resumption)TLSハンドシェイクはレイテンシと計算コストが必要となる。これを緩和するための機能が用意されている。セッションIDサーバがセッションIDとパラメータ情報をキャッシュし、クライアントもセッションIDをキャッシュすることで、暗号スイートと鍵の生成プロセスをスキップして、パケットの往復を一回削れる。サーバがすべてのクライアントのセッションキャッシュを維持し続ける必要があり、大規模サービスでは複数のサーバ間でセッションを利用できるような工夫が必要。セッションチケットセッションIDでのデプロイメントの問題を払拭するために、セッションチケットが公開された。この仕組みでは、サーバではセッション情報を保存せずに、TLSハンドシェイクの最後で、クライアントにセッションデータを返してクライアントが管理する。このセッション情報はサーバの秘密鍵で暗号化されているため安全。StartTLSのハンドシェイクの途中から、アプリケーションのデータの送信を行うことで、パケットの往復を減らすことができる。ハンドシェイクのロジック自体は変更せずに、クライアントがデータを読み取れるようになる鍵の交換をした時点から、データのやり取りを行う。TLS圧縮サーバでのTLS圧縮は無効にすべき。トランスポートレベルのTLS圧縮はコンテンツタイプを識別しないため、画像や動画などすでに圧縮されているデータを更に圧縮しようとする。そのため、二重に圧縮することでCPUを無駄に使用してしまう。証明書チェーンの長さ証明書チェーンのサイズを小さくするために、必要のない証明書はチェーンに含めないこと。ルート証明書を含める必要もない。単行本(ソフトカバー)目的、モチベーションOAuthの仕組みを雰囲気でしか理解していなかったので、理解を深めるため。普通の認可と違い、何故セキュアなのか。アプリケーションにSNS認証を導入する際に、どのように導入すればセキュアなのかを理解するため。読み進めていくうちに、OAuthは認証プロトコルではなく移譲プロトコルであるというのが特に衝撃的で、OAuthのことを全く理解していなかったんだなと思った。実際にコードを書いて簡単だが一連のやり取りを把握できたのが良かった。このパラメータがないと脆弱性につながるのかなども詳しく説明してあり、理解も深まりやすかった。入門書レベルだとは思うがボリュームもあり、OAuthを雰囲気で使っている人にはオススメ。2.0とは何か?そして、なぜ気にかけるべきなのか?OAuth2.0とは何か?委譲プロトコルで、アプリケーション(twitterなど)のリソースの所有者に認可されるように許可を求めて、クライアント(twitterのデータを利用しているサービスなど)トークンによって所有者の代わりにアクセスできるようにする仕組み。認可プロセスや暗号の方法などは定義しておらず、必ず認証がある訳ではなく、認証プロトコルでもない。2.0プロトコルの概要~トークンの取得と使用~標準的な流れは以下の通り。Grant)では、一時的なクレデンシャルである認可コードを使い、トークンを取得する。トークン、スコープ、認可付与アクセス・トークン中身のないただの文字列で、クライアントは内容を知らずに扱うことができる。スコープスペースで区切られた、保護対象リソースでの権限。リフレッシュ・トークン新しいアクセス・トークンを取得するのに必要なトークン。アクセス・トークンの期限が切れても、リソース所有者の認証を再度求めずに取得できる。認可付与OAuthのプロトコルを介して、アクセス権をクライアントが得る手段、即ちトークンを取得するフローのこと。OAuthの構成要素間のやり取りバック・チャネル・コミュニケーションリソース所有者やブラウザ以外の、認可サーバやクライアント、保護対象リソースのHTTPのコミュニケーションのこと。フロント・チャネル・コミュニケーションサーバとの、ブラウザを介したコミュニケーションのこと。ブラウザを介すため、機密情報は渡らない方がベター。シンプルなOAuthの認可サーバの構築この3つの章は、サンプルコードを元に実際に簡易なサーバを実装していった。手を動かすとイメージがつかめて良かった。インプリシット付与方式この付与形式では、認可エンドポイントから直接トークンを得る。クライアントがブラウザ内部に埋め込まれたJavaScriptアプリケーションのような場合、認可コードによる付与を行う際に、認可コードをクライアントに返すとブラウザに認可コードが渡ってしまいクライアント以外も知ってしまうため、メリットがない。ブラウザアプリケーションの場合、ユーザがいるためトークンが無効になっても再度認証を求められるため、TOFUも維持できる。クライアント・クレデンシャルによる付与方式バックエンドの認証などで、リソース所有者が明確に存在しなかったり、クライアント自体がリソース所有者の場合、この付与方式を用いる。scopeなどを指定して、認可エンドポイントから直接トークンを得る。リソース所有者のクレデンシャルによる付与方式リソース所有者のクレデンシャルをクライアントに送り、それを使って認可サーバからアクセストークンを得る方法。クライアントにクレデンシャルが渡り、アンチパターンなのでできれば避けるべき。仕様ではstateパラメータは必須でないが、CSRF攻撃を防ぐために検証した方が良い。クライアント・クレデンシャルの不当な取得ネイティブ・アプリケーションなどは、デコンパイルされる可能性が0ではないため、クレデンシャルは動的に取得するようにして、各デバイス毎にクライアントIDを管理した方が安全。リダイレクトURIの登録リダイレクトURIは攻撃されやすく、バグも発生しやすいので、完全一致で検証するのがベスト。サブディレクトリを検証しない場合、CGM型のサイトなどでユーザがページを作成できるときなどに、そのURLを指定されると漏洩の元になる。URLのパラメータにcodeが付与された状態で、攻撃者のページにリダイレクトした場合、imgやscriptを攻撃者のサイトにリクエストすることで、リファラー中のURLから盗まれる。パラメータの値のURLを検証せずに、そのURLにリダイレクトしてしまうこと。URIフラグメントにトークン情報を含めた状態でリダイレクトすると盗まれる。トークンの不正な取得Authorizationヘッダを利用できず、URLのパラメータに含める場合は攻撃されやすくなるので、注意が必要。保護対象リソースのエンドポイントの設計HTTPヘッダを適切に設定すれば、XSS対策をより安全に行える。MIMEスニッフィングを防ぐ。Security)を使えば、サーバ側で安全なHTTPSのみを使うように宣言できる。Strict-Transport-Securityを設定する。狙われるOAuthトークンの脆弱性トークンはシンプルである一方で、盗まれた際には何でもできてしまうため、工夫が必要。OAuthにおけるトークンとは何か?OAuthでは、トークンの形式は定められていない。用いられる乱数のトークンは、サイズを小さく保ちつつ、文字列を更に乱雑にすることでセキュアにできる。その一方で、認可サーバと保護対象リソースとの間でデータソースを共有できない場合は、通信処理がボトルネックになったりするなどのデメリットもある。Token)トークンそのものに、必要な情報を詰め込んだものの例として、JWTが紹介されていた。内部に情報を持つことで、認可サーバを介さずにリソースサーバがトークンの有効性やスコープを確認することができる。signature)の文字列から成る。文字列はJSONオブジェクトをBase64エンコードされている。トークンが盗まれた場合、デコードされるとpayloadの情報が読み取れてしまうので、HTTPSを使いかつ機密情報はトークンに含めないこと。Base64でエンコードされているのは、トークンを受け渡してる間にエンコードされてしまったり(URLのパーセントエンコーディングなど)して、処理を煩雑にしないための工夫である。Encryption)JWTでは、署名のアルゴリズムを指定することができる。例として、RS256を使うと秘密鍵を認証サーバで管理して、公開鍵をリソースサーバが受け取り検証することでセキュアに検証できる。Encryption)という仕組みもある。Introspection)トークン自身に情報を持たせると、scopeを最新の状態に更新できないなどのデメリットもある。Introspection。/introspectのようなエンドポイントを用意し、tokenの詳細の情報を取得できるようにして解決するプロトコルである。リクエスト数が増えて認可サーバに負荷がかかるので、リソースサーバ側でキャッシュするなどの工夫が必要。Revocationを利用する。アクセストークンとリフレッシュトークンを無効にするだけだが、攻撃されないように、トークンのクライアントとリクエストしてきたクライアントが一致するかの検証を行い、無効であったとしても201を返すこと。401を返すとDoS攻撃が行われ、他のクライアントでトークンが有効であることがわかってしまう。Registration)スケーラビリティを確保し、クライアントとの信頼関係を築くために動的にクライアントの管理を行いましょうという話だった。2.0自身は認証プロトコルでないが、認証プロトコルを構築するために用いられることもある。Connectが紹介されていた。OAuth2.0を使うプロトコルとプロファイルOAuth2.0を拡張したプロトコルやプロファイルが紹介されていた。Access)が利用できる。UMAでは、自分のリソースポリシーを設定し、Aliceを介さずにトークンを取得できる。トークンも第三者である利用者毎に発行できるため、revokeなどの処理も行える。処理の流れとしては、通常のOAuthに加えて、リソース所有者がポリシーを先に設定し、リソースサーバはトークンが有効な権限を持つか検証しないといけない。Trust)OAuthは柔軟な反面、相互運用性や互換性の確保が難しい。医療分野などの単一分野を取り扱っている場合、共通のAPIを利用することがよくあり、サーバ同士が連携しやすいように、ガイドラインが利便性が高まる。Trust)が紹介されていた。assurance)が紹介されていた。行政機関のシステムは、長期間使用される一方で、システムのアップデートが遅くなったりする傾向もあるため、互換性が担保できるように慎重に策定する必要がある。Bearerトークンの次のものBearerトークンはシンプルなため、トークンを奪われると再利用されてしまう。Possession:PoP)トークンと、TLSトークン・バインディングが紹介されていた。目的、モチベーションtwitterで知った。ベゾスが発してる情報源である株主への手紙を読み解いて、成長原則を学ぶというコンセプトが面白そうだったので、読んだ。果てなき野望」など何冊か読んだことがあったり、ネットの記事を読んだりしてたので、めちゃくちゃ目新しいものがあったかというと微妙。頭の中は整理できたり、復習にはなったりした。Principles」という14項目からなる信条とは別物で、著者が約20年分の株主へのレターからベゾスやAmazonが重視している原則を見出したものなので注意。メモ前段として、Amazonにおけるリスクの話があった。リスクは一般的には避けられるものだが、長期的に正しく進むためや、大きな革新やリターンを得るためには大胆に迅速に進める必要がある。そのため、ある程度は失敗する前提で学びを得られれば良しとしてリスクを犯すべき。14ヵ条は以下の通りで、企業文化として有名なものが多かった。常に1日目だと信じる特に印象に残ったのは、以下。顧客にこだわるユーザ本位というのは、どのような会社でも同じようなことを掲げるが、Amazonでは顧客に「すごい」と言われるような極端なレベルまでこだわるというのを徹底している。顧客の問題を解決するのではなく、問題を発生させずに完全に潰すのが仕事。徹底している一例として挙げられて面白かったのは、オンデマンドの映画を購入した顧客が見た時間帯に、顧客が気づかないレベルでネットワークの状態が少しだけ悪かったことをシステムが検知し、Amazon側から自ら顧客に謝罪と返金の連絡を行った。決定は迅速に行う大きい組織でも迅速に意思決定を行うために、「後戻りできない」ものと「失敗しても辞めたり取り返しのつく」ものの2種類に分類している。遅くなって手遅れになるよりも、情報不足で間違うことの方を良しとする。重要な項目を計測し、計測項目を疑い、自分の直感を信じる意思決定の際には数字をみて良し悪しの判断を勿論行っているが、スムーズにできる一方で、革新が起こりにくくもなるので数字は疑いもする。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。