amareloのブログ(仮)

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

cookieによるセッション管理とcookieの属性について

ウェブ・セキュリティ基礎試験勉強記事の2つ目。今回はcookie(クッキー)によるセッション管理とcookieの属性について書きます。

目次

参考文献

cookieとは

  • ステートレスなHTTPの仕様をそのままに、HTTPの仕様を拡張してWebアプリケーションとWebブラウザの間で情報交換、セッション管理を実現できるようにするための技術。
  • cookieが保持できる値の個数や文字列長には制限があること、利用者本人がcookieの値を参照変更できることから、秘密情報の格納には向かない。

cookieによるセッション管理

以下のような順番でセッション管理をします。

  • Webサーバからのレスポンス時に、WebサーバはCookieにセッションIDを格納します。
  • レスポンスヘッダの[Set-Cookie:]により、Webサーバはブラウザに対してCookie(セッションID)を保存するよう指示します。
  • cookie値を覚えたブラウザは、その後同じサイトにリクエストを送る際に覚えたCookie(セッションID)を送信します。
  • WebサーバはCookieを受け取ると、Cookieに格納されたセッションIDを基にしてメモリ上に持っているクライアントの状態を復元します。

セッション管理の要件

セッションIDは連番などではだめで、以下のような要件があります。

  • 三者がセッションIDを推測できないこと。
  • 三者からセッションIDを強制されないこと。
  • 三者にセッションIDが漏洩しないこと。

実際にはセッションIDの生成を自分たちで開発するのではなく、Webアプリケーション開発ツールにて提供されるセッションIDを利用した方が望ましいです。

セッションID漏洩の原因

セッションIDが漏洩すると他の利用者になりすましされる恐れがあります。セッションIDの漏洩の原因は、以下の通りです。

cookieの属性

cookieの属性は以下の通りです。

属性 意味
Domain ブラウザがcookie値を送信するサーバのドメイン。デフォルトではcookieをセットしたサーバのみに送信される。
Path ブラウザがcookie値を送信するURLディレクト
Expire cookieの有効期限(指定しない場合は、ブラウザ終了まで。)
Secure HTTPSの場合のみcookieを送信
HttpOnly JavaScriptからcookieにアクセス不可にする。

Domain設定

複数のサーバにcookieを送信したい場合は、Domain設定をします。 例えば、[Domain=example.jp]と設定すると、

  • a.example.jp 、b.example.jpにcookieが送信される。
  • a.examle.comには送信されない。
  • c.example.jpにはcookieを送信したくなくても送信されてしまう。

という動きになります。

ドメイン指定によりcookie漏洩(セッションID漏洩)の恐れがありますので、Domain設定は通常は設定しないことが望ましいです。

Secure属性

Secure属性設定を指定すると、HTTPSリクエストにのみcookieを送信します。これがないと、HTTPリクエストにもcookieを送信してしまいます。 平文でセッションIDを送ることになりますので、盗聴のリスクが発生します。

cookieにセキュア属性をつけることで、HTTPリクエストへのcookie送信を止めることができます。 ただ、HTTP/HTTPS混在のWebサイトの場合は、Webアプリケーションが動かなくなる恐れがあります。その場合は、別途トークンをチェックする対策が必要となります。

HttpOnly属性

JavaScriptからcookieにアクセスできないようにするための設定です。 XSSの影響を軽減する効果があります。ただし、根本的な対策にはならないため、XSSそのものの対策はする必要があります。

最後に

今回はcookieについてまとめました。HTTP(S)もcookieについても、この先脆弱性対策について理解するためにはちゃんと理解しておいた方が良いなと改めて思いました。 まだまだ「完全に理解した」わけではないので、たびたび見直しながら学習したいと思いました。

HTTPのGETメソッドとPOSTメソッドの違い

ウェブ・セキュリティ基礎試験(徳丸試験)を受験すると宣言してから随分と時間経ってしまいました。やっと着手できるようになりましたので、勉強再開します。 これからは、ウェブ・セキュリティ基礎試験について勉強したことをここに書いていこうと思います。

で、改めてGETメソッドとPOSTメソッドについて勉強しなおしましたが、「違いって何だっけ?」って思いましたので、整理しなおしました。

目次

参考文献

GETメソッド

  • 参照(リソースの取得)に使用する。
  • パラメータをURLに格納してリクエストをする。
  • 副作用(※)がないことを期待される。

※サーバ側でのデータ追加・更新・削除があること。同じ要求を何度繰り返しても同じ結果が得られること。

POSTメソッド

  • メッセージボディにパラメータ値を格納してリクエストをする。
  • 秘密情報を送信する場合に使用する。
  • 副作用がある場合に使う。
  • データ総量が多い場合(URLが長すぎる場合)に使用する。

秘密情報送信時にPOSTを使うべき理由

  • URL上のパラメータがReferer経由で外部に漏洩する恐れがあるため。
  • パラメータがサーバのアクセスログに残るため。
  • パラメータが入っているURLを利用者にSNSなどで公開される恐れがあるため。

Refererとは?

リンク元のURLを示すヘッダです。セキュリティ確保の目的でRefererチェックに使われたりもしますが、 アクセス者が意図的に書き換えることも可能です。 また、URLにセッションIDのような秘密情報を含んでいると、Refererヘッダから情報が外部に漏洩して、 なりすましに悪用される恐れがあります

最後に

今日はここまでにします。 これから勉強を進めるにあたり、不備不足がありましたら追記修正していきます。 短くてもアウトプットしながら学んでいけたらなぁと思います。

ssmonline #9「これからの時代の組織論 パネルディスカッション」参加レポート

4/28(水)、ssmonline #9「これからの時代の組織論 パネルディスカッション」に参加しました。

今回は沢渡さんと波田野さんと丸山さん3人のパネルディスカッションでした。始まる前から楽しみでした!

目次

イベントページ

ssmjp.connpass.com

togetter

togetter.com

セッション

沢渡さん これからの時代の組織論

資料

docs.google.com

  • 統制型マネジメントは確実性があるものに対しては有効。
    • しかし、統制型しか知らないと思考停止型人間を量産するリスクがある。不確実性に向き合えない。
  • イノベーションを生み出すには、統制型とオープン型のハイブリッドのマネジメントにシフトしていくこと。
  • デジタルワーク前提で時間で評価・拘束されない働き方が理想的。
  • 慣れた不便を言語化して、知的生産性を上げていく。

丸山さん 現場からみた運用組織論

運用をイノベーティブに変化していくためには

  • 変化に遅れない。
    • 運用のアジャイル
    • 意思決定の高速化
    • コミュニケーションの高速化(ホウレンソウからザッソウへ)
  • 先回りして速攻で相手のneedsを刺す。

    • 追うもののスタンスで。
    • 運用データ(監視アラート等)を情報に変え、傾向を読んで先手を打つ。
    • 問題を発見するスキルを身に付ける。
  • 測定できないものも管理する。

  • 権限移譲を積極的に行う。
  • 朝令暮改を変化に対する対応として前向きにとらえる。

  • 最適化が重要。

  • 「我々はどこにいるのか」を知り評価する。
  • 結果に対して謙虚になり正しく見直すこと。

波田野さん これからの時代の組織論

資料

speakerdeck.com

  • 組織はだいたい「硬直化・タコつぼ化」する。

    • 他部門の情報がなく、よその課題に興味を持てない。
    • 内部の最適化を求めて事業への貢献が後回しになる。
  • 硬直化・タコつぼ化を壊すには。

    • 情報の囲い込みをやめて情報をオープン化する。
    • 全体最適化指向になる。
      • 事業への最適化を求める。
    • 組織の構造を変える。
      • 機能的組織から事業的組織へ。またはその逆も。
  • ツリー型組織の弊害

  • ツリー型組織でオープンなコミュニケーションを実現するには

    • 経営が現場に任せる。
    • 現場に権限が必要。

パネルディスカッション

運用組織について

  • 運用組織は「運用実施」と「運用改善」がある。
    • 運用実施はオペレーティブ、運用改善はクリエイティブ。
    • それぞれ最適な組織や評価制度、スキル、マインドセットは違う。
    • オペレーションに興味がない人は、クリエイティブな仕事はできない。
    • オペレーティブ側の人をクリエイティブ側にすることで化ける人も一割ほどいる。
      • 組織がいかにそこに投資できるか。

人事領域とのコラボレーション

  • 会社文化がおかしいのは、人事制度もおかしい。
  • 人事担当者にもITリテラシーは必要。
  • 組織は人のつながりで存在するもの。ビジネスもコミュニケーションも大事。
  • 人事だけでなく、様々な組織が2.0にバージョンアップする必要がある。

守備範囲を広げるために

  • 自社サービスのドックフーディングをして、ユーザ側の問題点と担当者側の問題点を理解する。他人事にしない。
  • 日本の組織はグレーゾーン、野球でいうところの三遊間を拾わない傾向がある。
  • グレーゾーンを拾うためには
    • グレーゾーンの扱い方を定義する。
    • グレーゾーンを喜んで拾いたがる人に任せて正しく評価する。
      • クロスプレイになる可能性もあるが、それを怒らない風潮にすること。

最後に

あまりにもお三方の議論の濃度が濃すぎて、ついていくのがやっとでした(汗)が、ポイントとしては以下の通りかなと思いました。

  • 組織内外様々なつながりで組織はアップデートし成り立っていく。
  • 組織内向きの活動になりすぎず事業の成長に結びつくように。

改めて「組織」は生き物だなぁと思いました。生きていくためには成長していくことが大事。仕組みを作ったり改善をしても、それが事業の成長に結びつかないと不十分。 成長するためには当然一人の力では無理があるので、組織に所属する人たちがみんなで自分事となり協力し合える文化にできればなぁと思いました。 大変かもしれませんが、最初は一人で小さなことから工夫や改善をしていき、多くの人に伝搬できればと思いました。

熱い議論を聴くだけでも、「自分も頑張りたい!」と思えますね!力をもらってばかりでなく、誰かの力になれるようなアウトプットを自分もできるようになりたいです。

JAWS-UG朝会 #20 参加レポート

4.22(木)、JAWS-UG朝会に2か月ぶりに参加しました。今日も参加レポートを書いていきます。

目次

イベントページ

jawsug-asa.connpass.com

セッション

ラジオ体操

久々に本気でラジオ体操しましたw 良く体ほぐれました!!

はじめてのEKS Kubernetes案件 勉強方法 山田 俊一さん

資料

www.slideshare.net

概要

  • kubernetesは学習コストがあって、ネットも書籍も情報がありすぎてわからない。
  • 学習要点を洗い出し、優先度、現状、理想を目標設定する。
  • 学習要点ごとにレベル感をチェックし、体系立てて学習していく。
  • なんちゃって1人スクラムでPCDAをまわす。
    • 1週間を1スプリントとしてアウトプットを出していく。
    • 毎週上司と顧客にデモ、ふりかえり、改善を回していく。
  • ベースの学習にはEKS WORKSHOPが超おススメ。初級者のところまでやるのも学習になる。

AWS control towerの中身をみる 富松 広太さん

資料

www.slideshare.net

概要

  • AWS Control Tower とは、複数のアカウントを効率的に管理するためのサービス。
  • Landing Zoneが作られる(セキュリティとコンプライアンスのベストプラクティスに基づく環境)。
  • 違反作業の制限(予防的ガードレール)と違反作業の通知設定(発見的ガードレール)を有効にする。
  • 子アカウントにSCPの縛りがある場合はOrganizationsの方が良い。
  • これからマルチアカウント管理を始めるには、OrganizationsよりはControl Towerの方が良いかも。

お金がいっぱい溶けちゃったはなし sumiさん

資料

speakerdeck.com

概要

  • CloudEndure で80万円以上溶かした。
    • CloudEndure はオンプレのシステムをAWSに移行するためのシステム
  • 移行元サーバの容量(7TB)を把握しないままレプリケーションした。
  • 課金が怖く止めておいたが、移行元からはずっと同期されていた。
  • 移行元サーバの容量を把握していなかった。
  • 想定外の課金に気付けなかった。

  • 是正策としてAWS Budgetsで通知設定をした。

    • Budgetsは、使用料が予想を超えた時にアラートを出すサービス
  • AWS のコスト管理ツールはたくさんあるので、組み合わせてコスト管理するのも良い。

  • AWSは従量課金です!!

AWS Transfer Familyを触ってみた! ハンズラボ 中川 皓紘さん

資料

<公開されたら追記します。>

概要

  • AWS Transfamilyとは?
    • SFTP、FTP、FTPSでファイル転送ができるスケーラブルなマネージドサービス
    • SFTPサーバ立てるのと比べて管理コストがかからないので、SFTPサーバの面倒を見たくない人にはお勧め。
    • S3かEFSにデータ連携ができる。
    • 個別ユーザごとに細かなセキュリティ設定ができ、CloudWatchを使ったログ取得と解析ができる。
    • 料金が高くデメリットが大きい…

CloudTrail の証跡から IAM ポリシーを生成する IAM Access Analyzer の機能を AWS CLI から使ってみた話 弁護士ドットコム株式会社 伊藤 嘉洋さん

資料

speakerdeck.com

概要

  • IAM Access Analyzerの新機能について
    • CloudTrailの証跡(最大90日分)を解析してIAMポリシを作る。
      • 実際にはポリシドキュメント(JSON)を作る。
    • AWS CLIからも使える。
      • サブコマンド[accessanalyzer]が追加.された。

最後に

山田さんのKubernetesの勉強した時の話はとても参考になりました。目標を立てて体系的に学習していくこと、デモや報告を設定して進めることで自分も相手も理解を深められると思いました。自分も真似したくなりました!

sumiさんの80万円請求の話はビビりました。改めて料金通知設定は最重要と思いました。個人アカウントの通知設定と利用状況を見直さねば!個人で万単位のお金を溶かすとシャレにならない(汗)

今日はまだまだ知らないサービスの話が多く、勉強になりました。知らないサービスや技術の話を聞くと、もっとAWS勉強しようという気になりますね。また来月の朝会も参加したいです!

jawsug-asa.connpass.com

「エンジニアキャリア2.0~新時代の働き方、生き方を探る~」 参加レポート

4/17(土)、エンジニアtype様主催のカンファレンス「ENGINEER キャリアデザインウィーク」内の「エンジニアキャリア2.0~新時代の働き方、生き方を探る~」に参加しました。

目次

イベントページ

type.jp

ecdw2021.connpass.com

セッション概要

これからの時代、エンジニアの働き方はどう変わる?

「自分がどう生きたいか」を定義する

みなさん共通して仰っていたのは、一言でいうとこれかなと思いました。自分が楽しく働けるキャリアを自分で作ることが大事!もっと我を持って働いても良いのかもしれません。

  • エンジニアに限らず「私の働き方をこう変えていく」と言っていい時代だと思う(澤さん)。
  • テクノロジーによる課題解決にチャレンジしようとする人達が強い。自分自身がどうありたいか「個」の時代(戸倉さん)。
  • 会社に自分のキャリアを預ける今までの働き方はもう無理がある。キャリアの選択権を自分で持つこと(村上さん)。
  • エンジニアリングが分かっている人は強い。エンジニアの働き方はさらに広がると思う。

また、話の途中で「志」について触れていました。志はあった方が良いと思いますが、あまりにも志に対する気持ちが強すぎたり、志を決めなきゃと思うと動けなくなると思います。今の自分がそれかなぁって気づきました。

「志」を先に決めるのではなく、まずは「自分がどうありたいか」を見つめなおした方がよいと思いました。そこから「志」がついてくるのかなって思いました。

  • 志を持っていなかったが、持つ必要はないと思う(村上さん)。
  • 常に半歩先のことをやっていたら、場当たり的になる(澤さん)。
  • 志はキレイに見えるけど、ともすれば呪いの言葉になる(澤さん)。

組織との理想の関係は?

自分と会社はフラットな関係性が理想

会社は様々な保証をしてくれますが、会社に尽くせという丁稚奉公な文化が残っている。 ではなくて、お互いが良好な関係を気づき、パフォーマンスを出せる組織にする必要があると思いました。

  • 自分の気持ちを表現できる社風、自分を大事にしてくれる会社に勤めるのが理想的(戸倉さん)。
  • 会社と組織がお互いがいい具合で利用し合える関係。その会話が健全に出来るのが良い(村上さん)。
    • 全員が楽しくモチベーション高く働ける環境を作れる経営者は強い。
  • 自分が嬉しくなることを個々人がもう一度定義する(澤さん)。
    • 個々人の個性を生かせる会社は生産性が上がる。カオスな状況を十分に活用すればよい。

キャリア構築のヒントになる注目の「技術・働き方」トレンドは?

言語化能力

自分もこれが大事だと思い共感しかありません。自分がどうありたいか、どうしてほしいかを端的に表現して道を切り開く、自分の身を守ることを考えるためには、言語化能力が必要なのだと思いました。

澤さん
  • 具体化を一度抽象・汎用化して、別の具体化をできる能力が必要。
  • 経営者など非エンジニアの人々にテクノロジーのブリッジ(通訳)を出来る人が必要。エンジニアはみんなその候補生。
村上さん
  • 抽象化して一発でわかってもらうために、コミュニケーションスキル(ライティング、スピーキング等)が全職種に必要になる。
戸倉さん
  • 自分の身を守れるように考えることが必要。

転職するかしないかの見極めはどうしたらいいの?

ポイントは「市場価値を知ること」「自分らしくいられる環境かどうか」かなと思いました。市場価値を知って他社でやっていけるか、やっていけても自分の気持ちと折り合いをつけられる環境か、それに見通しが立てば転職に踏み出せるのかもしれないと思いました。

村上さん

  • 自分の市場価値を見極めるためにも転職活動は常にした方がいい。するつもりがなくても。
  • 辛い仕事を辛いままやり続けなくても良いように、自分の中で別のプランを作る。

澤さん

  • 自分に「タグ」が付いたと思ったら、いつでも転職できると思う。そのための活動をする。

戸倉さん

  • 自分が優先したいことができる会社が理想的。
  • 自分が必要とされているか?を見直す。
  • やりたいことに対してできたポジションに対して、「今しかない!」と思えたら迷わずGO!

【質問】一緒に仕事したいと思うエンジニアの条件

  • 課題認識を正しくできて、複数の提案をできて、それに対するリスクを正しく出せる人。(村上さん)
  • 船が難破して「こいつと一緒に生き延びることができるか?」と思える人。 スキル云々ではなくて人間力の方が大切。(澤さん)
  • 変化を楽しめる人(戸倉さん)

これは採用の立場からだけでなく、今いる環境についても当てはまるかもと思いました。こう思えなくなった人が近くにいたら、自分の成長も阻害されかねないし、楽しくなくなると思います。自分がこれを感じたら、転職など居場所を変えることもありなのかなぁと思いました。互いに敬意を持ちつつ、楽しく協力して仕事できる関係性が健全だと思いました。

【質問】新人ならばこれをやってけ!ということは?

澤さん

  • 筋トレ!体が健康なのは大切。

村上さん

  • 今いる場所で期待されていることの100%以上のことを出せるように動くこと。

戸倉さん

  • 所属書式の人やテクノロジーに興味を持つこと。
    • 役員やキーパーソンの名前を覚えることは人への興味の現れ。
  • 日記をつけておくこと。ふりかえりのために。

【質問】言語化能力を鍛える方法

皆さん共通して仰ってたのは Twitter!!140字以内に収めるのって、何気に大変なんですよねw自分も言語化能力向上を意識して使っていきたいと思いました!

澤さん

  • ツイートするにも食事の写真だけ等でなく、なぜこれを選んだかなどを書くと良い。
  • 音声メディア(Stand.fm、Voicyなど)で話すことも言語化能力を鍛えられる。

戸倉さん

  • ツイート内容への反応から伝え方の良しあしを確認をする。
  • レスポンスをスピーディーにすることにも意識する。

【質問】影響を受けた本は?

  • マーケターのように生きろ(戸倉さん)
  • 葉隠(澤さん)
    • 武士の生きざまが書かれており、現代にも通ずるところがある。
  • 「釈迦とバザール」「人を動かす」(村上さん)

英語の必要性

村上さん

  • 英語はもっともコスパのよいスキル。
  • 今から必死にやれば話せるレベルになる。リアルタイムに話すためには英会話が必要。

澤さん

  • 人間関係構築のためには自分で話せた方がいい。
    • 情報交換程度ならばリアルタイム翻訳でも良い。

最後に

  • 世の中を変えることに関与できる素晴らしい仕事。テクノロジーをキーワードに自分が活躍できる場を探して楽しんでもらいたい(戸倉さん)

  • 世の中を面白くする力を持っているんだと思って働いてもらいたい。色んな分野に欲張ってもらいたい。色んなところに自分の立ち位置を作ってほしい(澤さん)。

  • エンジニアには伸びしろしかない。全産業にICTが必要になる。テクノロジーの翻訳者などエンジニアのバックグラウンドになれるよう視野を広げて色々考えること(村上さん)。

まとめ

自分がどうなりたいか、どうすれば面白く生きられるか、それをアウトプットして伝えることで自分を守り世の中をよりよくしていくことができる。ブログ書いたりツイートしていることは間違っていない、もっと鍛えるつもりで取り組みたいと思いました!!「自分はどう生きたいのか」「どうやって世の中に貢献できるか」を自分はまだ定義できていないので、日々考え、言語化を繰り返していきたいと思いました。まだまだ言語化能力を鍛えられる、自分には伸びしろがありそうでワクワクしてきました!

澤さん、村上さん、戸倉さん、貴重なお話をありがとうございました!

土曜日の午前中に開催を企画していただいた主催の方々に感謝です!

ssmonline #10 参加レポート

4/15 ssmonline #10 に参加しましたので、レポートを書きます。

今回は「ヤマサキ春のサメまつり」でAWS SAMURAIの方々が参加するとのこと。AWSの話がたくさん聞けそうで楽しみにしていました。

ほとんどAWSの話は出てこずでしたが、楽しく勉強になるお話を聞けました!www

目次

イベントページ

ssmjp.connpass.com

Togetterまとめ

togetter.com

セッション内容

ぜんぶサメのせいだ! 山崎奈緒美さん

サメの被害の話

  • Internal Shark Attack File より、世界的に鮫に噛まれる件数は減少傾向。
  • サメの被害にあわないためには
    • 誰かと一緒に泳ぐこと。
    • 海岸の近くにいること。
    • アクセサリ類はつけない。

雪山情報

都内のキッチンカーでモウカザメを食してきた話 吉江瞬さん

資料

www.slideshare.net

SAMEYA(@kesenmiso)さんでサメトルティーヤとサメムニエル

  • サメはアンモニア臭が強いイメージだった。
    • 新鮮なサメで下処理をしてあればアンモニア臭を放たない。
  • 美味い!
    • 肉の食べ応えがある。
    • 鶏肉に近い感じ。
  • モウカザメは栄養価が高い。
    • DHAEPAが多い。
    • 低カロリー高たんぱく質
    • ビタミンB6、B12、鉄分が多い。
    • サケを捕食する。
  • SAMEYAオーナー高瀬さんと談義
    • 「サメ イベント」で検索したら、JAWS-UGのロゴが引っ掛かったとのことw
    • オンサイトイベントできたら、キッチンカー出店してもらうことの話を取り付けたw

SAMEYAオーナー高瀬さんより

  • キッチンカーで気仙沼のモウカザメを使ったバーガーを販売している。
  • サメは肝臓に油ため込むので身に油少ない。
  • 漁師の収入を上げるためにサメの食材価値を上げたい。
  • BASEでSAMEYAのTシャツも販売中。
高瀬さんの資料

www.slideshare.net

ヤマサキ春のサメまつり2019 被害者の会 三浦一樹さん

資料

speakerdeck.com

サメまつりに参加して出張報告に困った話

  • DAYSの会場でjunjunさんに出会う。
    • 運用の勉強会と思い込んで参加。
      • サメ映画の話、チョウザメの話…会社に報告する話がない…
      • 波田野さんの話のおかげで報告書を書けた。
        • 運用はサービスデリバリとして捉えたい。
    • 初めてのssmjpの感想は、めっちゃ楽しかった!

ssmjpのおかげでAWS Samurai 2019をいただいた話

  • ssmjpがなかったら、samuraiもらえてなかったかも。
  • 2019年年間17回登壇。
    • ssmjpのおかげで登壇のハードルがすごい下がった。楽しくやるのが一番。
    • みなさんも登壇しよう!

興ザメしないオンラインイベントを作るために取り組んできたこと 山口正徳さん

資料

speakerdeck.com

コミュニティのオンライン活動による課題

  • 慣れ、飽き、一方向になりがち・・・
  • 今のコミュニティ運営は今までの資産を切り崩していっているような状態。
  • どの課題も即時解決できない。将来つながることを今やっていこう。

JAWS-UG千葉支部の活動

  • 一緒にAWSを触って勉強しようを活動テーマに
  • ハンズオンを中心にした活動
  • オンラインでも一緒のスペースでハンズオンをしているという雰囲気の演出
  • 勉強するならば、運営も今まで触ったことがないサービスを触るチャレンジ
  • 人に説明するためには理解が必要
    • 一人で勉強するよりも効率が良い
  • オンライン開催はネガティブではなく、ポジティブな変化。
  • オンラインだからできるメリットを活かしてチャレンジしていく。
  • チャレンジしているところに興味を持つ人が集まる。

サメの話

  • コモリザメが海底に這いつくばるのは、岩になりすましてカニなどが寄ってきたことを食べるため。
    • 水族館で底でじっとしているのは習性。
  • 伊戸ダイビングサービスBOMMIE(館山市)でダイビング体験でサメを見れる。

JAWS-UGでのインプットとアウトプットの仕方 ~6年半の活動で見えてきた光と影 波田野裕一さん

資料

speakerdeck.com

なぜJAWS-UGの活動を続けられるか?

  • やりたいことが明確にある。
    • インプット、アウトプットしたい。
  • 情報を発信する人に、人は運営者に集まる。
    • アウトプットが増える。
    • インプットが増える。
  • パブリッククラウドのコミュニティは仕事と直結しやすい
    • 自分や参加者の仕事や転職につながりやすい。
    • インプットと仕事が近接
    • アウトプットが仕事につながる。

インプットの仕方

  • とにかく参加できるものに参加する。
    • 知り合いを1人でもつくる。その後も参加しやすくなる。
    • 初心者支部は運営もやさしい。ここから入るのがお勧め。
  • インプットした情報をすぐ使ってみる。
    • やってみたを自分の引き出しとしてたくさん作る。
    • 知ってるからやってみたに進化させる。ここまで来る人は少ないので、勉強したら早めにやること。
  • 自分の軸になる興味テーマを持つ。
    • 興味と仕事を絡められる人は本当に強い。ツヨツヨ系の人はみんなそう。
    • 「興味テーマの組み合わせ」が他人と違うのが独自性につながる。

アウトプットの仕方

  • 何でも良いので「内容のある発信」をする。

    • 「やってみた」はどんな内容でも価値がある。失敗は特に価値がある。
    • 情報は発信者に集まりやすい。反応がなくてもへこまないことが大事!
    • 参加者が持って帰れる物を発信すること。
  • 発信したネタを整理して登壇してみる。

    • LTの登壇をやってみる。
  • 自分の得意・興味があるところに手を出す。

    • 運営もアウトプットの一つ。
    • 人があまり手を出さないテーマに手を出す。
      • 興味がそのまま仕事にできたり、興味の赴くまま仕事を変えることも。

6年半の活動で見えてきた影

  • AWSJAWS-UGは、独立性を持った別物と理解する。
  • JAWS-UGのメンバーとは互恵の精神で、相互にビジネス観点で最大限に活用すべき。

    • あとは常識的な行動ができていればよい。
  • 困った人

    • 運営の肩書だけで活動しない人、運営メンバーを名乗る人
    • 発表の時に質問せずに個別に聞きに来る人
      • 運営と登壇者は、貴重な時間と工数を無償で提供しているのでやめてほしい。
    • 過剰に内輪感を出す人
    • 「本番は懇親会から」と参加者側から言う人。
      • 初参加者に疎外感を感じさせてしまう。

感想

語彙力ないかもですがw、面白く勉強になったの一言に尽きます。

山崎さんのお話聞いて北海道行きたくなりました! ゲレンデから海が見えるSNOW CRUISE ONZE、行ってみたいです!

吉江さんとSAMEYAさんのオーナー高瀬さんのサメの話を聞いて、料理としてのサメを始めて知りましたし、サメを食べたくなりました(書いてて腹減ってきたw)。

三浦さんのssmjpのおかげでAWS Samuraiを受賞できたお話、山口さんの千葉支部運営のお話、波田野さんのアウトプットとインプットの話を聞いて、また登壇したい欲、チャレンジしたい欲が高ぶってきました。

今日登壇者皆さんのお話を聞いて、

  • 登壇は楽しく。
  • チャレンジしているところに興味を持つ人が集まる。
  • アウトプットする人のところに情報が集まる。
  • アウトプットをすることで自分がしたいことを引き寄せる。

改めて認識しました。最近チャレンジらしいことをアウトプットできてなかったし、登壇もなかなかできなかったので、時間作ってチャレンジします!

「とにかくやれそうなことは何でもやってみよう!」

最後に

次回のssmjpは4/28(水)。波田野さんと沢渡さんのパネルディスカッション。楽しみしかありません!!!

ssmjp.connpass.com

ICMPについて(ネットワークスペシャリスト勉強自分メモ)

ネットワークスペシャリスト試験(4/18)まであと1週間になってしまいました(汗)自信はまったくありません… ICMPについてもまだ理解不足だったので、自分メモ書きます。

目次

参考図書とサイト

参考図書は下記の通りですが、これから自分が書く内容には認識不足があるかもしれません。誤りや不足などありましたらご指摘ください。

ICMP(Internet Control Message Protocol)とは

主なICMPメッセージタイプ

ICMPメッセージには問い合わせ(照会)メッセージとエラーメッセージがあります。

タイプ 内容 照会 or エラー
0 エコー応答 Echo Reply 照会
3 到達不能 Destination Unreachable エラー
5 リダイレクト Redirect エラー
8 エコー要求 Echo Request 照会
11 時間超過 Time Exceeded エラー

ICMPエコー応答とエコー要求

宛先ホストにIPパケットの到達可否を確認するために使われます。 まず、エコー要求メッセージを送ります。エコー応答を受信すれば到達可能です。 pingコマンドが代表的なところです。

ICMP到達不能メッセージ

宛先にIPデータを配送できない、つまり経路途中で転送エラーや宛先ホストで受信エラーが発生した時は、送信元にホストにICMP到達不能メッセージ(宛先到達不能メッセージ)を送信します。 配送できなかった理由が分かるようにするためです。

主なICMP到達不能メッセージは以下の通りです。

コード番号 ICMP到達不能メッセージ 概要
0 ネットワーク到達不能 Network Unreachable 宛先IPアドレスへの経路情報を持っていないかった。
1 ホスト到達不能 Host Unreachable 宛先コンピュータがネットワーク接続していなかった(宛先コンピュータの経路情報がない)。
2 プロトコル到達不能 Protocol Unreachable プロトコルが宛先コンピュータで使われていない。
3 ポート到達不能 Port Unreachable 宛先ポートが宛先コンピュータで使われていない。TCPヘッダ内の宛先ポートが見つからない場合は接続リセットを返信。
4 分割処理が必要だが、分割禁止フラグが設定されている Fragmentation Needed and Don't Fragment was Set MTUの値を送信元に返信する。送信元は、このメッセージを受け取ることで経路MTUを設定した通信をすることができる。

ICMPリダイレクトメッセージ

送信元ホストが最適でない経路のルータにデータを送った時に、ルータが最適な経路のルータにパケットを転送するのと同時に、送信元に返信するメッセージです。 送信元はリダイレクトメッセージを受けてルーティングテーブルを変更します。そうすることで、以降の通信は最適な経路のルータにデータを送信するようになります。

時間超過メッセージ

パケットがルータを1つ通過するたびに、IPパケット内にある生存時間(TTL:Time To Live)の値が1つ減ります。TTLの値が0になったら、ルータはIPデータを破棄して送信元ホストにICMP時間超過メッセージを送信します

TTLが決められている理由

TTL値が0になる主な理由は、経路内にループが発生している時です。ループによって、パケットが永久にネットワーク内に輻輳を発生させないようにするためです。

経路MTU探索

宛先ホストにデータを送信する際に、分割処理が必要ならない最大MTU(経路MTU)を探索します。 こうすることで、送信元ホストは経路MTUの大きさにデータを分割して送信するため、 途中のルータで分割処理を行う必要がなくなります。 そのやり取りの中で、ICMP到達不能メッセージコード番号4が使われます。

経路MTU探索の仕組み

  • 送信元は、最初の通信でIPヘッダのフラグメント禁止ビット(DFビット)を1に設定してパケットを送る。
    • 途中のルータは分割処理を行わずに宛先に送ろうとする。
  • 途中のルータのMTUが送信元のMTU値を超えていた場合、ルータは分割せずにパケットを破棄する。
  • ルータは、ICMP到達不能メッセージコード番号4とMTUの値を送信元に返信します
  • 送信元は受信したMTU値を経路MTUとして設定し、パケットをMTU値のサイズに分割して送信する。
  • 送信元は経路MTUの値を10分程度キャッシュする。
  • 10分経過したら、再度経路MTU探索をします。

最後に

代表的なところだけを書きましたが、改めてまとめるとやはり理解していないなぁと思うばかりです… でも、参考書籍を読めるので良いと思います。試験勉強の時こそ本を読んだことをまとめて、可能な限り手を動かした方がいいなぁと思いました。 あと1週間ではあまりブログにまとめることはできないかもしれませんが、もうひと踏ん張り頑張ります!