amareloのブログ（仮）

IT系勉強会で感じた想いや知見をメインに書いていきます。

喜びに満ちた人生を送りたい

3/6 に「デブサミ再演！クリエーションライン安田氏が語るどん底からのジョイインクジャーニー7年記」をオンライン受講しましたので、感想を書きます。

イベントについて

hacker-life-lab.connpass.com

Developers Summit 2020 の再演です。自分は別のセッションに参加していましたので聴けませんでした。企画していただき、運営の皆様には感謝です！！

スライド

www.slideshare.net

安田さんのセッション

お話の概要

  • Joy,Inc.に出会う前は、社内の雰囲気が悪く機能しないチームだった。
  • そんな状況を変えたく、社内懇親会、ヴァル研究所見学、「強いチームの作り方」ワークショップを実施。
    • 目的を伝え、大事なことには投資し、フォロワーが出るまではくじけず続ける 。
  • 2017年8月ごろ、JoyIncに出会う。最初は遠い世界のようなことに感じていた。
  • RSGT2018でリッチーさんの講演を聞き、楽しそうに仕事のことを話している姿を見て、自分も楽しく語りたいと思うようになった。
  • RSGT2018週明けの全体会議から、楽しく仕事して新しい価値を生み出すための実践を始めた。
  • 日本のいろいろなチームにJoyIncの文化を広めたい。
  • 会社の文化がよくなるとよい結果が生まれ、会社の業績がよくなる。残業も少なくなり労働環境の改善にもつながる。
  • あなたは喜びに満ちた人生を送りたいですか？

Joy,Inc.の特徴

Joy,Inc.の名言

  • 会話が関係を作り関係が価値を作る
  • すばやくたくさん間違えようという文化
  • 最良の人たちを維持するためならばなんでもやる
  • 一番大事なのは人であってスキルではない

楽しく仕事して新しい価値を生み出すための実践例

  • お互いを知るためのリレートーク（自己紹介）
  • Weekly朝会
  • 業務時間として雑談
  • 財務情報フルオープン（契約形態問わず全メンバー）
    • 主体的に動いてもらいたいため、あらゆる情報を性善説に基づいて公開

感想

今回のブログタイトルは、「あなたは喜びに満ちた人生を送りたいですか？」の答えです（「いいえ」と答える人はいないと思いますが…）。楽しく仕事したいし、職場や仕事に対してもっとコミットしたい。しかし、そのためには、誰かが声を上げて行動し、周りを巻き込んでいかなければならない。苦労も並大抵ではない。安田さんは楽しそうに話しているように見えましたが、今日に至るまで大変な苦労をされていたのではないかと思いました。

自分が「喜びに満ちた人生を送る」ためにはどうすればいいか？

1.自分の「好き」を仕事にし、そこに関わる人たちを「好き」になる。

2.すべての仕事を自分事としてとらえ、情熱をもって取り組む。

この2つかと思います。

前回の記事でも書きましたが、自分が本当に楽しく仕事するには「情熱」が必要だと思いました。自分は、今楽しく仕事をできている人たちは、「苦労」と「情熱」を併せ持った人たちだと思います。前者しか持たない人はたくさんいると思います。今の自分も前者寄りだと思いますが、それで人生終わりにしたくない。やはり自分が好きなことを仕事にしてそこにフルコミットしたい。その中で同じベクトルを持つ人たちと繋がり、その人たちも好きになりたい。そして、お互いに楽しく仕事できるようなことを考えながら過ごせれば、自分も自分に関わってくれる人たちにとってもとても素敵なことになると思います。そこに至るまで時間はかかりますが、現状を変えるために勉強してスキルを付けたいし、視野も広げたいです。また、今回の安田さんが実践されてきたことも、自分ができそうなところから実践したいです。

最後に

最近の世相からカンファレンスや勉強会が中止を余儀なくされる中で、今回のような企画をしていただけたのは本当に嬉しかったですし、勇気づけられました。また、デブサミに行けなかった人にとっても、何よりも嬉しい企画だったのではないかと思います。改めて感謝します！！

AWS ソリューションアーキテクトアソシエイトの勉強進捗

先週、AWS ソリューションアーキテクトアソシエイト（以下、SAA）の勉強を急がねば！と書きました。1週間経ちましたので、ここで勉強の進捗を書きます。

先週の記事

amarelo24.hatenablog.com

今日までにやったこと

  • 参考書の読み込み
  • 参考書の模擬試験実施
  • セルフペースラボの実施
  • Udemy申し込み

先週書いたことの一部は着手はできました。参考書の模擬試験もやってみましたが、「このままではマズい！！」という成績でした…

セルフペースラボで初めてLambdaとS3を操作しました。やったことは、S3に画像がアップされたことをトリガにして、画像をリサイズして別のS3バケットに補完するというものでしたが、Lambdaというものが何か、サーバレスが何かということを少しですが実感できました。サーバレスで何かやれることがないか考えたくなり、ワクワクしてきました。

これからやること

  • 参考書の補完

    • ホワイトペーパーなどAWS公式のドキュメントを読む
    • Udemy受講

  • 実践

    • Udemyハンズオン実施
    • 模擬試験実施（Udemy付属のもの、AWS公式のものどちらか）

参考書付属の模擬試験で合格に十分な点数ではないため、焦りしかありません。少しでもハンズオンや試験形式で経験値を積むべく、Udemyの「AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座」に申し込みました。

セールで大幅値引きされた時に申し込みましたので、安く申し込みできました。講義・ハンズオン・模擬試験とかなりボリューミーな内容となっていますので、講義部分は通勤時間など空き時間を有効活用し、家に帰ったらハンズオンをして理解を深めていきたいです。

最後に

ブログ書かずに勉強しろとツッコまれそうですが、週に一度進捗確認して必要なことは宣言して進めないと、途中でくじけそうなので書いています。なので、今日はここで終わります！

Developers Summit 2020 に参加して

2/13、14の2日間、Developers Summit 2020（以下デブサミ）に参加してきました。

フル参加というわけにはいきませんでしたが、数多くの講演を聞くことができました。 とにかく登壇者の熱量がひしひしと伝わってきて、退屈になる隙などありませんでした。 すべてのセッションを聞きたいくらいでした。

今回は講演ごとの内容を書くより、今の自分の想いを書こうと思います。 講演の内容はtogetterでまとめられていますので、そちらをご覧ください。

デブサミ公式ページ

event.shoeisha.jp

講演資料、togetterまとめ

codezine.jp

自分の想い

今回は「エンジニア組織」「エンジニアの生き方」のカテゴリに該当する講演を中心に聴講させていただきましたが、どの講演にも言葉に魂が篭っていると感じました。ここまで熱量ある話をできるまでには、並々ならぬ苦労があったと思われます。おそらくですが、

  • 自分事になる
  • 情熱を持つ
  • 探究（深堀り）する
  • 信頼される
  • 覚悟をする

これらを意識して自分のやるべきことに取り組んだからであり、登壇者の熱量はそれに裏付けされたものだと思いました。

今の自分がどうかと思い返してみると、仕事も趣味のコーヒー焙煎も、自分事として情熱持って楽しく取り組めているレベルではないと思いました。特に「探求すること」については、本当に足りていないと思います。

仕事については、もちろん所属組織に迷惑をかけるようなことは今のところしていませんが、「仕事だから」という気持ちで取り組んでいる感がまだ抜けていないように思えます。勉強も幅広くするようにはなりましたが、表面だけで浅く広くから抜け出せていません。仕事のこと、興味がある分野の勉強も、深掘りするほど情熱を注げていないと思います。自分がやっていることにもっと向き合えるようになりたいです。

コーヒーについても、普段やっている焙煎、抽出、豆のこと、もっと深堀りできるところはあるはずだけど、そこまではやれていないです。新しい知見が得られるかもしれないし、違った角度でコーヒーの良さを伝えられるようになるかもしれません。また、コーヒーを通じた良い縁を作れるかもしれないし、本職にも何か良い影響を与えられるかもしれません。まず何ができるか深く考えてみます。

「探求」をし続けることが「情熱」、「信頼」につながっていき、周りを巻き込むことができ、何かを「ともにつくる」ことができるのではないかと思いました。これはエンジニアだけでなく、すべての職種の人に通ずることだと思いました。

最後に

2日間様々な講演を聞き、たくさんの刺激をもらえました。デブサミの講演には楽しく参加できるので、今後もできる限り参加したいです。

将来、誰かの仕事のヒントになりそうなことをカンファレンスの講演などで話せるよう、仕事も勉強も趣味も取り組んでいきます。

AWS ソリューションアーキテクトアソシエイトに向けて

1月の記事で今年の目標的なことを書きましたが、そのうち、

AWSソリューションアーキテクトアソシエイト 受験

については早急にやらねば！！と火が付き、勉強のペースを上げました。

※1月の記事「2020年にやりたいこと（その２）」 amarelo24.hatenablog.com

はじめに

AWS認定試験は3月にバージョンアップするとのことです。以下には実施日まで書いていませんが、今のところ3月22日の予定のようです（間違っていたらすいません）。

aws.amazon.com

試験の難易度の変化、受験費の増減、何があるのかは分かっていませんが、これまで勉強してきたこととは違った形になる。 これまで勉強してきたことをベースにして受験するには、3月22日までに受験せねばならない！もうゆっくりしてられない（汗）と思うようになりました。

ちなみに、自分がAWSソリューションアーキテクトアソシエイト（以下、SAA）の勉強を始めたのは去年の11月。 バージョンアップの話はちらっと聞きましたが、じっくり勉強して臨むため、あまりペースを気にせずに勉強していました。 しかし、気が付けばもう2月！！何をやってたのか…

やること

ケツに火がついた以上、前に進むしかありません。今やろうと思っていることは、

  • 参考書の読み込み（実施済だけど何度も繰り返す）
  • BlackBelt オンラインセミナーの視聴
  • アカウント作ってハンズオン
  • セルフペースラボの実施
  • その他AWS関連の書籍（できれば）
  • 模擬試験

こんなところを考えていますが、他にもやった方がよいこと等あったら、ご教示いただけると幸いです。 しかし、1か月でやり切れるのか…

最後に

受験することを決意表明しないと何もやらずに終わりそうなので、取り急ぎここに書き記しました。大急ぎで準備して受験しますが、試験に受かることが目的ではなく、ちゃんと理解した上で臨みたいと思っています。

無謀かもしれませんが、挑戦します！短いですが、今回はこの辺で。

planioをはじめてみた

突然ですが、planio（プラニオ）を個人で使い始めてみましたので、そのことを書こうかと思います。

planio とは？

Redmineをベースにしたプロジェクト管理のためのクラウドサービスです。

plan.io

ファーエンドテクノロジー株式会社様がPlanio認定パートナーとして、

  • 日本国内でのプロモーション
  • 日本語サポート
  • サービスとWebサイトの日本語化

を行い、サポートをしていただいております。 そのため、Redmineに慣れている方にはなじみやすいサービスかと思います。

www.farend.co.jp

planioをはじめた理由

プライベートのタスク管理をできるようになりたい

これが理由です。自分はタスク管理が下手です（仕事もプライベートも）。タスクそのものを忘れることはあまりないのですが、なかなか手をつけられない。ひどいと放置してしまう。 短期的なタスクならまだしも、長期的タスクの中にさらにより細かいタスクがあると、考慮漏れがあり、詰めも甘くなります。 プライベートタスクをちゃんと管理できなければ、仕事のタスク管理もできないのでは？と思うようになり、何とかしたいと思っていました。 特に今年は年始に2本、今年の目標的な記事を公開しました。

2020年にやりたいこと - amareloのブログ（仮）

2020年にやりたいこと（その２） - amareloのブログ（仮）

ここで公開したからには、

「今年の目標を立てたが、年末に振り返ってみたら何もできずに終わってた」

みたいなことにはしたくない！そう思い、ちゃんと今年の終わりには成果を残せたと思えるよう活動したいと考えていました。

こんなことを考えていたちょうどその時、普段からお世話になっているオンラインコミュニティ、インフラ勉強会にて「redmine生活はいいぞ」というセッションが登録されたことを知りました。

※補足：インフラ勉強会 wp.infra-workshop.tech

私生活でのplanioの利用について紹介されるため、セッション前に予習として自分もplanio使うことにしました。 ひとまず自分が勉強したいことについて、何をいつまでにやるのか、どこをゴールにするのかを登録しました。 当日のセッションは、登壇者のかふぇさんが実際にplanioを使っている様子を見せながら進んでいきました。 自分の経験を財産にし、効率化、履歴活用のためにplanioを活用されているお話を聞き、自分も経験の財産化したい！と思いました。 また、年末に振り返るときに何となく振り返るのではなく、具体的に振り返りできるようにしたいため、planioを本格活用する気持ちになりました。

planioを使ってみて

現在の使い方

先述の通り、自分が直近勉強したいことを３つほど登録しました。 勉強したいことの管理が当面の目標になるため、中長期的なタスク管理として使っています。 勉強したいことの大項目をチケット登録し、それに関連する小項目を子チケットとして登録してみました。 それぞれのチケットを見るのでなくガントチャートで見れば、進捗やタスク被りがわかりますので、 今の自分にはこの使い方がしっくりきているかなと思います。 まず登録したことが落ち着いてきたら、過去記事で書いたことも登録して少しずつ進めていきたいと思います。

使ってみての気づき

自分の性格面での気づき

とりあえずチケット登録したものの、1/31現在クローズできたチケットはまだありません。 やりたいことがたくさんあり、日常の時間をやりくりしながら勉強しているため、正直進捗はあまりよろしくありません。 つくづく、優先順位設定の下手さに改めて気づかされました。また、いかに自分が希望的観測でスケジュール決めてるのかも気づきました。 とはいえ、自分一人しか見ないチケットではあるものの、一度チケット切ったらやり遂げたいという気持ちにはなりました。

スケジュール通りにいかなかったら見直しながら進めるしかないのですが、何にどのくらい時間がかかるなど、 一タスクにかかる大体の時間見積もりをうまくできるようになれればと思います。

ツール利用面での気づき

planioはクラウドで使えるため、スマホがあればいつでもチケットを見たり登録できるので、 やるべき子タスク増えたり、やりたいことが増えたらすぐに登録できるのが良いです。 アプリの動作が少しモサっとしているように思いますが、大きな不満は今のところないです。 アラート通知をアプリで受けることができますし、To Doリストのように毎日見なければならないわけでもないので、今のところ継続して使えそうな感覚です。 その毎日見なきゃっていう変な強迫観念が嫌で、自分はTo Doリストがあまり好きではないのかな？と気づきました。

あと、アプリのキャラクター？がかわいい（笑）

最後に

まだ使い始めたばかりなので、うまく使えておらずplanioのメリットデメリットを理解できていないと思います。 上手くタスク管理、経験の財産化できるよう、工夫しながら使っていきたいです。 気づいたことや有効活用できるようになったら、ブログにも書きたいなと思います。

セキュリティ共有勉強会 参加レポート

1/24（金）にセキュリティ共有勉強会に参加してきました。遅くなりましたが、参加レポートです。

イベントページ

intra-security.connpass.com

今回のテーマ

今回は「社内教育」がテーマでした。社内教育への考え方、ISMSについてがメインの話でした。以下、登壇者のお話です。

奥山歩さん（@a_okusan）　セキュリティ教育ってなにしたらいいの？

資料

docs.google.com

感想と概要

セキュリティ教育を軽く見る人多いけど、行動するための基準を知らないと、社員はセキュリティを守れない。目的を再認識してもらえるよう工夫しなければならないと思いました。

  • セキュリティ教育は、セキュリティポリシーの周知徹底のため実施。立派なポリシーも機能しないと本番で動けない。
  • 幹部、セキュリティ管理者、技術者、一般ユーザ、それぞれに実施する。対象によって内容を変化させる。
  • 一般ユーザには、明確な行動、基礎知識（こんなことあったら会社が潰れるよ等）、自社としての対策（規定やルール）を教育する。陳腐化するので定期的に。
  • 気づいていない大事なことを自分事として気づかせることが大切。

丸山ゆきえさん ISMSと社内教育

資料

www.slideshare.net

感想と概要

丸山さんは、この1年間で1人でガイドライン作ったり、教育やったり、Windows7全部捨てたり、といったことをやってきたとのこと。情シスになって4年目のよわよわ情シスと仰っていましたが、行動力もスピード感もあって十分つよつよだと思いました。自分も見習いたいです！

  • ISMSとは究極のPDCA

  • 教育もPDCA

    • P：教育のプランを立てる。
    • D：教育のテストを作成する。
    • C：回答を集計する
      • 出さないような人には急かしたり（実施率100%になるまで追い回す）、会議でさらす。

  • 社内教育はまず自分教育。自分が理解することが重要。検定を受けたくなる程までに。

  • まずはエンジニアに頑張ってもらう必要がある。何より謙虚に接して理解してもらう。

gd30secさん：素人がゼロから社内CTFを企画開催した話

資料

drive.google.com

感想と概要

セキュリティ教育は、セキュリティに詳しい人でないとできないと思い込んでいましたが、セキュリティ未経験者でも工夫次第で教育を作れるし、何よりもやる気なんだなと思いました。

  • 社長から社内SECCONの企画を命じられた
  • 取り扱う技術領域
    • ネットワーク機器、サーバの脆弱性を対象にした
  • 競技形式
    • 運営1人では採点できないため、全チームRedTeam形式にした
  • 評価形式
    • ハッキングの採点と報告プレゼンの内容

  • 非技術者分野

    • 高校数学でわかる暗号解読問題にした
    • 技術分野と非技術分野のリンク

  • 社内SECCON後、実施したことをサービス化

  • 認定ホワイトハッカーの資格を取得

uchiday13さん：こんな社内教育どうでしょう

資料

www.slideshare.net

感想と概要

金融機関のセキュリティ対策ということもあり、かなり徹底的にやられている印象を受けました。特にメール誤送信対策は、どこの企業でもなくせないセキュリティ事故ですが、根気よく教育するのがベターなのだと再認識しました。他のお話も参考になりました！

  • いろいろとメール誤送信対策したが、実は社内教育が一番効果があった！

    • 指差し点検など宛先確認の動作ルールの教育を3か月連続で行い、誤送信した人には三重の違反として扱った。

  • 不信メール訓練を継続的に実施し、開封率を全社に開示。報告率の高い部署をほめた。

  • 携帯電話紛失として、なくしたら弁償金徴収、携帯に届け出先ラベル貼り付けを取り入れたが、社員の壁が高くまだまだ導入途中。

FGtatsuroさん：会社で一番ISMSが嫌いな社員が語るISMSとの付き合い方

資料

www.slideshare.net

感想と概要

認証は取ることが目的になりがちだと思います。ISMSはセキュリティを守れていることの証明なので、普段から職員が効果的にPDCAを回せるよう、環境面の改善も工夫する必要があることに気づきました。個人的には今回の勉強会で一番刺さった発表でした。

  • ISMSの規格を満たす方法は明示されていない。職員がISMSに興味を持ってもらえるよう、業務と親和性がある環境や運用方法にカスタマイズする。
  • 必ずしもISMSを取得している企業 != セキュアな企業 ではない。
  • ISMSを自分事として取り組むならば価値はある。他人事ではお金の無駄になる。自分事にすることが大切。

飛び入りLT

  • 教育をどうするか悩んだら、個人と組織と時間を考える。
    • 個人のレベルが低いならば、足りない部分を教育
    • 組織のレベルが低いならば、ルールを作り徹底させる。
    • それを時間かけて続けていく。
  • 入社試験で足切りのセキュリティテストをやった方がよいのでは？
    • セキュリティテストが一般化すれば、学生も真剣に勉強してくる。意識ない人に教えるより、意識ある人を採用した方が楽。

お悩み相談会

  • どうすれば工数をかけない社内教育を実現できるか？

    • 社内のセキュリティレベルを把握し、その人に合う教育をする。全部に同じ教育をしようとしても、工数が増えるだけ。

  • 受講者参加型の教育のノウハウは？

    • ゲーム型の教材がある。CTFもある（準備は大変）。
      • 脱出ゲームはおすすめ！

  • MDMがないのにリモートワークをスタート。どうすれば・・・

    • スタートするな！w

など、一部ですが、このようなお悩み相談がありました。

終了後

残っていた参加者で軽く食事に行きました。こんなこと聞きたいなど、勉強会の今後のテーマのこと、セキュリティに関する話が尽きませんでした。最後までいたかったですが、終電の関係でお先に失礼しました。

最後に

今回の気づきは、この3点です。

  • 教育の目的を伝え自分事にしてもらう
  • 教育を受講しやすく効果が上がるような工夫をする
  • ルールを守れるような業務環境や仕組みを作る

これはセキュリティに限らず、こちらから他人に何かを実践してもらいたい時も同じだと思います。取り組みやすい環境とその意義を伝え、ハードルを下げないと、ただ「やって！」ではきっと人は動きません。工夫を加えて何度もPDCAを回していくしかないと思いました。

それでも、スムーズにセキュリティ教育を遂行するのはことは難しいですが、効果があることを再認識しました。自分も真剣に取り組まねばならないです！

次回テーマは、「リスクマネジメント」

また刺激的なお話を聞くことができそうで楽しみです！

HTTP/Tokyo #1 に参加して

昨日、HTTP/Tokyo という初めて開催された勉強会に参加して来ました。そこで得た知見を書こうと思います。

HTTP/Tokyo について

以下のイベントページにも書いてありますが、HTTPというプロトコルについて理解し、HTTPを正しく使えるようになることを目指す勉強会です。HTTP(s)に特化した勉強会って無かったので、面白そうと思い参加しました。

http-tokyo.connpass.com

会場提供 株式会社トレタ様について

corp.toreta.in

  • 外食産業の生産性を向上させるための事業を展開している。
  • 飲食店向け予約／顧客管理サービスを展開
  • 超直前予約アプリToreta nowの開発元
  • 立ち呑みトレタ 1/29 19:30から

会場はおしゃれできれいな雰囲気でした。全従業員の自宅勤務を推奨していたことからも、フレキシブルに働けそうな感じがしました。立ち呑みトレタ、興味あります！

Response Status Codes 3xx　あらや @arayaryoma さん

資料

https://slides.araya.dev/http-tokyo-1/#slide=1

概要

ステータスコード 3xx系についての話でした。302はよく聞きますが、それ以外はあまり聞かないので、3xx系のステータスコードの多さに驚きました！！3xx系のコードについてはもっと勉強する必要あるのかと思いますが、登壇と資料で学んだこととしては以下の通りです。

  • ステータスコード 3xx は、リクエストを果たすためには UA によるさらなるアクションが必要ということを指示する。
  • 301と302はHTTP/1.0で定義されたもの

  • 初期の UA では、301, 302 だったとき、リクエストターゲットへの適用に差があった。

    • HTTP1.1で実際の差分に影響されない307が追加された

  • 300 Multiple Choices

    • リダイレクト先の候補がいくつかある、クライアント側は優先したいものを選ぶという仕組み。

  • 301 Moved Permanently

    • 対象のリソースに新たなURIがあてられていて、このリソースへの今後の参照は同封されたURIのいずれかを利用すべきことを指示する。
    • UA は後続のリクエストのメソッドを POST から GET へ変更してもよい。

  • 302 Found

    • 対象のリソースが一時的に異なるURIのもとに配置されていることを指示する。
    • UA は後続のリクエストのメソッドを POST から GET へ変更してもよい。

  • 303 See Other

    • UAに対し異なるリソースへのダイレクトすることを指示する。
    • UAは受け取ったロケーションヘッダフィールドのURIをターゲットとするリクエストを発行できる。

  • 304 Not Modified

    • 条件付きGET/HEADリクエストが受け取られ、条件がfalseと評価されていなければ、200で応答するかのように返す挙動をとる。

  • 307 Temporary Redirect

    • 対象リソースが別の URI の下に一時的に存在し、UA がその URI への自動リダイレクトを実行する場合、リクエストメソッドを変更してはならない

  • 308 Permanent Redirect

    • 対象のリソースに新しい恒久的な URI が充てられていて、このリソースへの今後の参照は同封された URI のいずれかを利用するべきことを指示する。
    • リクエストメソッドを POST から GET に変更できない。

Status425 @flano_yuki さん

資料

www.slideshare.net

概要

ステータスコード425とTLS１.3でも使われるEarly Dataについての説明でした。コード425なんて初めて知りました（汗）Early Dataも初めて知りましたので、興味深く聞くことができました。TLS1.3についても話が聞けるとは思ってもいなかったため、得した気分でした！

  • TLS1.3について

    • TLSハンドシェイクにはプルハンドシェイクと0-RTTハンドシェイクの２種類ある。
      • フルハンドシェイク
      • 0-RTTハンドシェイクは、一度ハンドシェイクした相手と再度ハンドシェイクする際にアプリケーションデータ（Http Request)を送信する。それをEarly Dataという。
    • Early Data はリプレイ攻撃に悪用される危険性がある。リクエストの中身は分からないが複製できる。
    • サーバはHTTPリクエストを見て、冪等でないリクエストを拒否できる。

  • TLS1.3を踏まえた上で、425 Too Early とは？

    • RFC8470 Using Early Data in HTTP で定義されるステータスコード
    • 安全にEarly Dataを送信できるようにするための仕様

  • ProxyやCDNを経由させている場合の問題点

    • Proxyを経由する環境の場合、ProxyはEarlyData のリクエストが冪等か判断できないため、そのままOriginサーバに経由してしまう。
    • OriginサーバもProxyから送られてきたリクエストが、もともとEarlyDataで送られてきたものかわからない。

  • 問題解決のために

    • ProxyがEarlyDataを経由する際に「Early-Data リクエストヘッダ」を追加する。
    • Originサーバはリクエストが冪等でない場合、425 Too Early を返してリクエストを拒否できるようにする。

おまけ 418 vs 425

  • Too Early のステータスコードを決める際に418にするか425にするか議論したが、418はIANAの管理上使われていなかった。
  • しかし、エイプリルフールに発行されたジョークRFC（RFC2324 Hyper Text Coffee Pot Control Protocol）で定義された、418 I'm a tea pot があり、あちこちに実装されていた。そのため425になった。
  • RFC7230 - 7237 から仕様を再改定することとなり、418はUnusedとなった。

@flano_yuki さんのブログ

asnokaze.hatenablog.com

Cookieについて Jxck さん

概要

Cookieについての説明をホワイトボードに書きながら登壇されていました。あまり見たことない登壇スタイルだったので驚きました。聞き漏らさないよう真剣に聞きました。途中から理解が追い付かなったところがあり、Cookieについて再勉強しなければと思いました。

資料はありませんでしたが、RFC6265とHTTP State Tokenをもとにした話でした。

tools.ietf.org

tools.ietf.org

※自分の理解が追い付かなかったため、わかった（と思う）ところのみ書きます。誤認識の恐れもあります。申し訳ありません。

  • Cookieはリクエスト送信者を識別するために作られた。そのため、格納情報のほとんどはクレデンシャル情報である。
  • サーバは最初のレスポンスでSet-Cookieを送り、クライアントにCookieを保管させる。次回以降はそのCookieを送信させることでアクセス元を判断している。
  • しかし、CookieがSame Originの原則に乗っ取っていないため、悪意ある人が成りすまして正規のCookieを含んだリクエストを送っても、サーバはリクエストを受け付けてしまう。その性質を悪用したのがCSRFである。
  • CSRFトークンでリクエストの正否を判断する必要がある。
  • Cookieの方が歴史が古く、SameOriginの概念の方が新た強い。だから、ドメインの扱いが歪になっている。
  • 一般的にCookieを悪用されないための対策は以下の通り。
    • secure属性をつける。
    • HttpOnly属性をつける。
    • Path属性をつける。
    • ドメイン属性は基本指定してはいけない。サブドメインにもCookieを送ってしまうので、意図せずCookieが漏洩する恐れがある。
  • Set-Cookieを送信する際に「SameSite」というプロパティを付けることができるようになった。
    • クロスサイトオリジンなサイトの場合は、SameSIteを明示的に"none"にする必要がある。
    • SameSiteをlaxに設定すると、サイトの挙動を壊す恐れがある。
  • サードパーティCookieによるトラッキングを防ぐため、ブラウザ側で対策が施されている。
  • Cookieをなくすことはできないが、ChromeはCookieに頼らない情報収集（APIの利用等）を考えている。
  • Prefix __secureを付けることでHTTPSの時のみ送信を許可。Set-Cookieの上書きを防ぐことができる。
  • 画面を遷移してきたときにどこから来たのかを識別するために、できれば、ReadとWriteのCookieを判別できるようにするのがよい。そうすれば、SameSiteの属性を使い分けられる。
  • Cookieではなく、「クライアント側でトークンを生成してサーバに送る」http state tokenの提案がされている。

最後に

HTTP(s)は、Webサービスがある以上、なくなることも廃れることもないプロトコルであり、アップデートされていくものだと再認識しました。奥が深いです！途中ついていけなかったくらいでした（汗）勉強し直します！もちろん、httpに限らず、Webサーバ、Webプログラミングなど、Web周辺のことはもっと知りたいと思います！

次回が開催されたら、また参加したいと思えた勉強会でした。