amareloのブログ（仮）

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

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

AWS 勉強会レポート

目次

はじめに

6/20 JAWS-UG朝会 #46 の参加レポートです。 今日はre:Inforceのお話が多く、re:Inforce行きたくなりました。

イベントページ

jawsug-asa.connpass.com

セッション

セッション① AWSのセキュリティイベントre:Inforceいってきた！朝刊版 アマゾン ウェブ サービス ジャパン合同会社 松本 照吾さん

概要

  • AWS re:Inforce
    • AWSセキュリティとコンプライアンスに特化したグローバルカンファレンス
    • １つのコンデンションセンターで行われてちょうどよい規模感
    • 同じ興味を持つ人と交流できる
    • その場でしか得られないプライスレスな経験
    • 今年はジャパンツアーを実施
      • CISOのCJ Mosesによるジャパンツアー向け特別講演
      • 感想LTなど参加者との交流
  • AWS re:Inforc2023 re:Cap Seminar を6/29に実施

aws-startup-lofts.com

感想

re:Inforceはre:Inventと比べると、セキュリティに特化していて規模感も大きすぎないところが良い、 興味のベクトルが同じ方を向いている人が多そうで、参加してみたくなりました。

そのためには、ただただお金の問題を解決しないとですね…

セッション② 今更ながらAmazon DynamoDB の論文を真面目に読んでみた 加藤雅己さん

資料

speakerdeck.com

概要

  • 2022年7月に公開された論文を読んだ

    • DynamoDBのアーキテクチャとその進化の歴史
    • サービスの中身を知った方がいいものを作れると思った。
    • AWSの顧客体験への強い意志を感じた。

  • DynamoDBの特徴

    • NoSQLデータベースらしいシンプルなクエリ構造
    • 書き込みの負荷分散は難しい
    • Put/Get/Scanなどシンプルなクエリしかサポートしない
      • その代わりにパフォーマンスがテーブルのサイズ、リクエスト量によらず一貫
    • キャパシティが不足していればスロットルがかかる

  • DynamoDBのアーキテクチャ

  • プロビジョンドからオンデマンドへの旅

    • テーブルのスループットをパーティションに均等に割り当て
      • 合計スループットがノードの限界を超えないように配置
        • 特定なキー領域へのアクセス集中してしまう。
    • バーストによる瞬間的なリクエスト増大の吸収
    • キャパシティ調整による空間的リクエスト分布の吸収
      • 特定なキー領域へのアクセス集中の課題は残る
    • テーブル全域の監視による不当なスロットルの防止
    • 消費キャパシティの監視によるパーティションの適切な配置換え
    • リクエストが集中するパーティションの分割

  • まとめ

    • 出てきた課題に対し、迅速に対応可能な部分から改善していく姿勢を見習いたい
    • せめと守りの仕組みを作ることで安全なアプリケーションを設計できる
    • 裏側を知ることでより良いアプリケーションを設計できるのではないか。

感想

英語の論文とはいえ、13ページ程度とのことなので、英語の勉強もかねて自分も読んでみようと思いました。 DynamoDBの復習になってとても良いセッションでした。

DynamoDBの論文

https://www.usenix.org/system/files/atc22-elhemali.pdf

LT① アナハイムに行ってきた！AWS re:Inforce 2023参加報告（速報版） ニューリジェンセキュリティ株式会社 大島悠司さん

資料

speakerdeck.com

概要

  • ジャパンツアーに参加
  • Japan Nightでツアー参加者同士の交流
  • 基調講演に最前列で参加
    • セキュリティは最優先事項
    • 常に大量のログを分析してセキュリティ向上に寄与している。
  • EXPO
    • 様々なセキュリティ製品の最新技術を知れる。
  • ハンズオンセッション
    • 当日発表されたサービスをいち早く触ることができた。
  • CISOのCJ Mosesによるジャパンツアー向け特別講演
  • ロサンゼルス視察

感想

re:Inforceもre:Inventも熱量が高くて一度は参加してみたいと常々思っています。 現地で交流しながら新しい技術に触れてハンズオンした経験を共有いただけると、その気持ちがより高まります。

繰り返しですが、お金が。。。

LT② AWS Shield Advancedの設計して得られたノウハウ NTTデータ・アイ 遠藤大介さん

資料

qiita.com

概要

  • AWS Shieldとは
    • DDoS防御
    • L3,L4層を保護
  • Advanced
  • SRTとの問い合わせは英語で
    • 日本語サポートの場合はSRTと直接やり取りできない。
    • 平日9:00～18:00のベストエフォート対応になってしまう。
    • 英語で起票することで24/365の対応や直接のやり取りが可能
  • WAFログ用バケットの暗号化方式に気を付ける
    • SRTチーム用のWAFアクセス権限を与えることで、DDoS時に対応するカスタムWAFルール作成のサポートを受けられる。
    • WAFログを保存する暗号化方式をSSE-S3にする必要がある。
  • WAFのルールは惜しまず活用すべし
    • 統合しているWAFの基本料金が含まれる
    • 1500WCUまでは追加料金がかからない。必要なルールは適用するのが良い。
  • API Gateway は可能であればCloudFrontと統合して利用すべし
    • API Gateway はShield Advancedと統合できない。
    • 前段にCloudFrontと置いて、WAFとShield Advancedを統合する。

感想

Shield Advanced 普段使えなくて（金銭的に）あまり勉強できないサービスなので、Tipsの共有とてもありがたいです！勉強になりました！！

LT③ Amazon FSx on ONTAPをさわってみたはなし（仮） めるさん

資料

speakerdeck.com

概要

  • NetApp社のONTAPを使用したファイルシステムフルマネージドサービス
  • 重複排除の性能が良い
  • SnapMirrorによるファイル転送
  • 詰まった点
    • ONTAP CLIを実行するにあたりSSHアクセスできない
      • セキュリティグループはアタッチされたENIに対して付与されている
      • そのセキュリティグループの設定もれだった。
  • 今後やりたいこと
    • リソース作成手順のCLI化
    • SnapMirrorでの移行
    • FabricPoolによる階層化

感想

Amazon FSx もONTAPもなかなか触る機会がないので、知見や詰まった点を共有いただけるのは、本当にありがたいことだなぁと思いました。

最後に

re:Inforceのお話、英語の論文を読んだお話、AWSの勉強だけでなく英語の勉強もしたくなりました。 やりたいことが増えるのはいいけど、なかなか手が回らないのも考え物ですね。どうしたものか。。。

今月も朝会の開催、ありがとうございました！

「AWS Direct Connectと愉快なGWたちをおさらいする会」受講レポート

AWS 勉強会レポート

目次

はじめに

6/6（火）に開催された「AWS Direct Connectと愉快なGWたちをおさらいする会」を聴講しました。 お昼休み中でながら参加になったしまったのですが、Direct Connect（DX）とTrangit Gatewayについてガッツリ扱う勉強会でしたので、 ANS（AWS Certified Advanced Networking - Specialty）再々チャレンジのためにももう一度腰を据えて復習したいと思える勉強会でした。

なので、動画公開していただけて感謝しかありません！！ 受講レポートが遅くなってしまいましたが、今日6/11（日）に公開します。

イベントページ

minorun365.connpass.com

AWS Direct Connectと愉快なGWたちのおさらい みのるん さん

資料

speakerdeck.com

概要

  • 自社のオンプレ環境とVPCにDicrect Connect(DX)を引くには

    • 自社のオンプレ環境
      • ルータを置いて設定。
    • DXロケーション
      • ネットワーク事業者にルータを手配（もしくは自分で設定）
      • DXロケーション内にあるAWSのルータに配線
    • 自身のAWSアカウント
      • VGWを作成
      • ネットワーク事業者にVIF（仮想インタフェース）作成を手配し、マネコンで承認する。

  • Direct Connect学習するにはマネコンを覗いてみよう

    • 接続
      • DXロケーション内の自社ルータとAWSルータを接続して仮想回線を複数引けるようにする。
    • VIF
      • 仮想回線
      • 1本ごとに異なるVLAN IDを持つ
    • 仮想プライベートゲートウェイ（VGW）
      • オンプレとVPC間で閉域アクセスする際の出入口
    • LAG（リンクアグリゲーション）
      • 複数の接続を束ねて１本にする。

  • 接続の３種類

    • 占有型
      • 接続もVIFもユーザのもの
      • VIFも作り放題
      • お金はかかる
    • ホスト接続
      • 仮想接続をユーザに一部提供
      • VIFはユーザのもの
    • 共有型
      • 接続はNW事業者のもの
      • VIFはユーザのもの
      • 他の利用者と共用するけど、値段は安い。

  • Direct Connect Gateway と Trangit Gateway

    • Direct Connect Gateway(DXGW)
      • VIFを増やさずに接続先のVGWを20個まで関連付けできる。
      • VPC同士の通信はできない。
    • Trangit Gateway(TGW)
      • VPCを5000個までアタッチ
      • VPC間の相互通信も可能

  • ３つのVIF

    • プライベートVIF
      • プライベートIPを用いてオンプレとVPC間を通信する。
    • パブリックVIF
      • S3、DynamoDBなどVPC外のAWSサービスと専用線接続する際に使う。
    • トランジットVIF
      • TGWとつなげたい場合に使う。
      • 占有型かホスト接続でのみ利用可能。
        • 共有型の場合は使えない。
          • VPC間相互接続をしたい場合は、別途Trangit Gatewayを作ってVPCにアタッチすれば、トランジットVIFは不要。ただし、DXGW接続上限の20は変わらない。

  • 課金発生ポイント

    • 構成例：NW管理部門がDXGWを集約管理。利用部門アカウントを関連付けて運用
      • DXGWのポート使用料にて課金(NW管理部門AWSアカウント)
      • VIFデータ戦送料で課金（利用部門AWSアカウント）

  • DXのSLA

    • シングル構成：95%
    • マルチサイト（非冗長）:99.9%
    • マルチサイト（冗長）：99.99%

  • BGP設定

    • オンプレ側ルータとVGWのASN（自立システム番号）は重複不可能
    • DXGWより先はASN重複可
    • 定期メンテナンスがある際に経路制御をする設定
      • Local Preferense
        • AS内部でルータの優先度を定義
      • AS Path
        • ルートを経由するASの一覧。少ないホップ数のルートが優先される。
        • Prepend設定でホップ数を変更可能
    • NW障害検知に使われる設定
      • Keepaliveインターバル
        • ダウン検知時間。障害検知に時間がかかる。
      • BFD（双方向フォワーディング検出）
        • 隣接ルータ間で生存確認。約1秒でダウン検知可能。
        • ネットワーク環境で使える場合のみ設定可能。

所感

短い時間でDXの必要な要点がすべてまとめられていて、かつわかりやすかったです。 ANSの勉強で覚えてきたことの再確認、不足点を再認識することができました。 接続の3種類について、これまで違いを理解せずにANS臨んでたんだなぁって思うと、自分まだまだだったんだなぁって思いました。

LT① Transit Gatewayを使わなければならない場面を改めて考えてみる　のんぴさん

資料

speakerdeck.com

概要

  • Trangit Gateway を使わなければならない場面

    • オンプレと直接通信を行うVPCが20個を超えるとき
      • 20個以上のVPCとオンプレを直接通信をする必要があるか？
        • RDPやSSH接続したくても、SSMセッションマネージャでも可能
        • ADと疎通させたいならば、AWS上にAD DCを立ててオンプレのADと同期とることも可能。
    • 複数のVPC間を相互接続したい場合
      • そのVPC間を相互通信する必要があるか？
        • VPC10個をすべてTrangit Gatewayに接続すると、1か月約511ドルかかる（東京リージョン）。
        • コストを最優先するならば、相互接続するVPC数が少ないならば
          • 共有VPCから各VPCにPeering接続することでも実現可能。
      • VPC Peeringがメッシュ状になり、運用管理コストがランニングコストを上回る時はTrangit Gatewayの出番になりうる。
        • 構成をすっきりさせたい場合
    • VPC間、VPCとオンプレ間の接続を捻じ曲げたい場合
      • インターネットに出る際に特定VPCを通るようにしたい場合
      • VPC間の通信をNetwork Firewallを経由したい場合
    • Site-to-Site VPNでECMPを使いたい場合
    • SD-WAN製品と連携させたい場合

  • Trangit VIFがサポートされておらず、Trangit Gatewayで接続できないことが多い。

    • WANのプロバイダがTrangit VIFを提供しているかが重要
    • Trangit VIFをサポートするプロバイダに接続する必要があるが、その接続コスト（ルータ選定変更、プロバイダへの支払いなど）をどう見るか。

所感

Trangit Gateway があることでネットワークの利便性はあがるとはいえ、一般的な利用シーンはあるとはいえ、 本当に相互接続が必要か、費用や運用コストの兼ね合いはどうか、それをしっかり考えなければならないと改めて気づきました。 ハンズオンで使っていてもかなりお金かかるサービスですし、費用対効果は慎重に考えないとですね。

LT② DX接続タイプの違いが説明できるようになろう 〜「完全に理解した」になるための第一歩 〜　はたはたさん

資料

speakerdeck.com

概要

  • 接続の違いを知ることの重要性

    • 仕様がパートナーのサービス提供形態、接続のタイプに左右される
    • 接続の違いを知ることで、要件にあったパートナー選定、サービス選定ができる！

  • 専有型、共有型、ホスト接続の違い

    • 前提
      • Connectionの中にVIFが存在する
      • 接続タイプによって、誰がどの部分を所持・管理しているのかが異なる。
    • 専有型
      • ConnectionもVIFもユーザに提供
      • ユーザが自由にVIFを作成削除できる。
      • トランジットVIFも使える。
    • 共有型
      • Connectionはパートナーが所有、VIFをユーザが所有
      • VIF作成の際はパートナーに依頼しなければならない。
      • トランジットVIFは使えない。
    • ホスト接続
      • パートナーが持っているConnectionの中に仮想的なConnection（Hosted Connection）を作成
      • Hosted Connection１つにつき１つVIFを作成できる。
      • トランジットVIFも使える。

  • 注意点

    • 各パートナーの経路広報設定の差異
      • ネットワーク設計と異なる仕様である恐れがあるので、事前にパートナーに確認すること。
    • DXとパートナーのサービス使用は別
      • トランジットVIFが使えない（共有型だった）ことがあるので、必ず確認すること。

所感

DXとしての接続（Connection）と、サービスとしての仕様、違いがあるのは初めて知りました。 普段、構築側・導入側でないと、まったく持っていない観点だったので勉強になりました。

LT③ イメージがわかると見方が変わる Direct Connect SiteLink　粟ケ窪 康平さん

資料

speakerdeck.com

概要

  • Direct Connect SiteLink とは

    • オンプレのデータセンタ間の相互接続をDXGWを介して可能に。

  • DX は、どのAWSリージョンにも、どこのDXロケーションからでも接続できる。

    • DXGWはリージョンの概念がないグローバルリソース
    • DXロケーションはAWSネットワークへの入口
    • Direct Connect SiteLinkは、世界を股にかけて閉域接続できる機能

  • 注意点

    • VPC間相互通信は不可能であることは変わらない。
      • VPC Peering かTGWを使うこと。
    • SiteLinkの有効化はDXGWからではなく、VIFから行う。

所感

Direct Connect SiteLink、まったく知らない機能でした。 言われてみれば、BlackBeltの資料にもANSの書籍にも書いてなかった。。。 DXGW介してのオンプレ間閉域接続の要件があった時の実現方法を知れたのはよかったです。 Direct Connectは奥深いと思いました。

LT④ はじめてのDirect Connectとつまづき 　宇都宮 郁香さん

資料

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

概要

  • 接続方式をホスト接続から専有型へ変更

    • DXのランニングコストは、ポート使用料とデータ転送料に大別される。
      • ポート使用料
        • DXロケーション内で、AWSまたはDXパートナーのネットワーク機器を使うために、ポートがプロビジョニングされている時間に対して課金
          • データを通過しなくても発生する料金
        • ホスト接続の場合は、ポートを所有しているパートナーに請求
        • 専用接続の場合は、ポートを所有しているAWSアカウントに請求
      • データ転送料
        • データ転送アウト：AWSからAWS外（オンプレなど）へのトラフィック
          • データ転送元となるAWSサービスを所有するアカウントに請求
        • データ転送イン：外部からAWSへのトラフィック
          • 課金対象外

  • 実際に触ってみないとわからないことだらけ

    • まずは接続方式と、GW、VIFの概要と特徴を理解すること。
      • 躓いていたことはここの理解が足りないことで起こっていた。
      • コストについてもここを理解することですんなりといった。
    • DXの理解が足りない人は、今回の勉強会を復習しよう！

所感

DXの課金ポイント、まだ理解できていませんでしたが、やはり接続方式の理解が足りなかったからと認識できました。 なかなか触れないサービスですが、接続方式とVIFについては忘れないよう注意したいです。 DXの理解が足りない人は今回の勉強会を復習しよう、ほんとそれだと思いました。

最後に

２回ANS不合格だったとはいえ、勉強してきたことの下地があってすっと聞くことができました。 また、まったく知らない機能（Direct Connect SiteLink）を学習でき、接続方式についてほとんど理解していなかったことに気づき、 お昼休み1時間の勉強会でしたが、DXとTrangit Gateway盛りだくさん、内容の濃い勉強会でした。 これに参加してからANSリベンジに臨めばよかった…と思う程でした。

みのるんさんはじめ、登壇していただいた皆様には感謝です。ありがとうございました！ Direct Connect、Trangit Gatewayの学習への意欲、ANS再々挑戦への意欲も湧いてきました！！

AWS Certified Advanced Networking - Specialty(ANS-C01)を2回受験して不合格だった件

AWS

目次

はじめに

3月と5月にAWS Certified Advanced Networking - Specialty(ANS-C01)を受験しました。

2回とも「不合格」

※1回目：695点、2回目：722点

AWS認定で初の2連敗…悔しい思いをしましたので、反省と整理のためにブログを書こうと思います。

筆者のスキルセット

自分は、所属企業の情報セキュリティ施策の企画、運用、統制を担当しています。 エンジニアとしてアプリ開発やインフラ構築にガッツリ関わった経験は乏しく、ネットワークをはじめどの分野も広く浅く知っているという程度です。 AWSを業務で直接触る機会はありませんが、個人でAWSアカウントを作って細々と勉強して、認定試験を何とか６つ（CLF、SAA、DVA、SOA、SAP、SCS）合格できました。

受験までにやったこと

試験ガイドを読む

まず最初に出題内容と試験の対象となるサービスを確認します。 ここに書いてあることを基にして、後述する書籍やAWS公式ドキュメントを読んで勉強しました。

https://d1.awsstatic.com/ja_JP/training-and-certification/docs-advnetworking-spec/AWS-Certified-Advanced-Networking-Specialty_Exam-Guide.pdf

書籍

要点整理から攻略する『AWS認定 高度なネットワーキング-専門知識』 (Compass Booksシリーズ) | NRIネットコム株式会社, 佐々木 拓郎, 小西 秀和, 安藤 裕紀, 木美 雄太, 早川 愛, 宮川 亮, 矢野 純平 |本 | 通販 | Amazon

ANS-C00（改定前バージョン）の内容ですが、ANS-C01の範囲となっているサービスの説明もありますので、読むべき書籍です。 練習問題も試験と同じ65問ありますので、良い練習になりました。

AWS公式ドキュメント

書籍と併用して読みました。どのドキュメントという指定はありませんが、AWSが公開しているドキュメントや情報のうち、 試験の対象となるサービスに関係するものはできる限り読みました。

ハンズオンとワークショップ

ネットワーク、サーバレス、セキュリティ、コンテナのハンズオン・ワークショップをやりました。 以下のサイト「JP Contents Hub」にハンズオン・ワークショップがまとめられています。

aws-samples.github.io

自分が実施した中でもやった方がよいと思ったハンズオンは以下です。

時間とお金は結構かかりますが、 Transit Gateway を学べる良い教材だと思います。

catalog.us-east-1.prod.workshops.aws

  • Edge Services Immersion Day Workshop

時間はかかりますが、CloudFront、AWS WAF、Global Acceleratorについて幅広く学ぶことができて内容が豊富です。 CloudFront function、Lambda@Edgeが何なのかまったく分からなかったので、このハンズオンで感覚をつかむことができたのは良かったと思っています。

catalog.workshops.aws

全編英語のハンズオンのため、「JP Contents Hub」には記載されていないワークショップです。 Network Firewallの勉強をしたかったため、頑張って英語を読みながら（一部Google翻訳を使いながら）実施しました。 他のサービスと比較してお金がかかるサービス（Trangit Gateway ・NATゲートウェイなど）がハンズオン構成の中に含まれています。 Trangit Gatewayを学べてNetwork Firewallを学べて良いワークショップですが、使用料には注意です。

catalog.workshops.aws

スキルビルダー

explore.skillbuilder.aws

ANSに関する講座を受講しました。ANSの練習問題（15問）もここから何度でも受けることができます。

サンプル問題

こちらも試験前までに何度もやりました。

https://d1.awsstatic.com/ja_JP/training-and-certification/docs-advnetworking-spec/AWS-Certified-Advanced-Networking-Specialty_Sample-Questions.pdf

ANS受験した感覚

「AWS認定最難関試験は嘘じゃない」という感想につきます。

170分で65問解かなければなりませんので、1問あたり約2.5分しか取れません。 問題文が長く複雑で（相変わらず翻訳が微妙なところもあった）、2.5分で解くのは余程理解がないと厳しいです。 理解していても、読み解くだけで精神力と集中力と体力を消費します。2回とも最初の10問くらいで心が折れそうになりました。。。

半分（32問）解いたあたりでやっと長文にも慣れてきましたが、時すでに遅し。。。 見直しをする余裕はなく、何とか時間内に65問を解いたという結果でした。

反省点

最初から長文に真正面から解こうとしたこと

１問目から真正面から長文を解こうとすると、精神力と集中力と体力を削がれ、時間が経つごとに厳しくなります。 焦って要らぬ判断ミスをする要因になってしまうと思いますし、ともすればそれが原因で落とした問題もあったかもしれません。

１回目はバカ正直に長文問題から取り組んだせいで、全問解答するのに時間ギリギリまでかかりました。 ２回目は比較的短い問題、パッと見で１分以内で解けそうな問題から解く戦法で臨みました。 しかし、最初から長文かつ複雑な問題ばかりだったため、飛ばしても効果はなさそうと思い、途中から前回と同じ戦法に変えてしまいました。 それでも１回目よりは数問見直しはできましたが、途中で意思を曲げずに、比較的簡単な問題を余裕のあるうちに解いて、 その後に飛ばした問題を落ち着いて解いた方が良かったのかもしれません。

エアコン対策

受験した日の外気温は少し暑いくらいでした。しかし、テストセンターは体が冷えるくらいエアコンがかかっていました。 長袖を持っていきましたが、それでも後半は体が冷えて少し集中力を欠いた感じがしました。 次回受験する時期がいつになるかは分かりませんが、たとえ夏でも少し厚着と思うくらいの準備はしていった方が良いかもしれません。

テストセンター（オフライン）で受験するのが望ましい

２回ともテストセンター（2回とも同じ場所）で受験しました。

自宅から近いところにテストセンターがないため、自宅で試験の設営をしなければならないためです。 余計なところに思考を割くよりは、直前まで試験勉強に時間を充てた方が良いと思いました。

また、すべてのテストセンターがそうかは分かりませんが、自分が受験したテストセンターではホワイトボードシートを使えました。 オンラインでは紙にメモをすることはできませんので、これは大きなメリットだと思います。 おかげで、頭の中を整理しながら解くことができました（それでも結果は不合格…）。

高難易度の試験に関しては、時間の有効活用と脳の整理をできるオフライン受験の方が望ましいです。 オンライン、オフラインどちらもメリットデメリットあって良いのですが、 ホワイトボードシートを使わず頭だけで考えるオンライン受験は、ANSではキツイです（汗　 コロナ禍落ち着いてきた今、今後受ける高難易度の試験は、オフライン受験を中心にして、 どうしてもという時にオンラインにした方が望ましいと思います。

要件に沿った設計や運用を考えることができていない

Specially試験は、どうやったら要件に沿った設計や運用のベストプラクティスを考えられるか、 そのために使うサービスは何かを考えられる能力が、アソシエイト試験以上に問われていると思いました。 自分はそれを考えられる能力が乏しいのでは？と思いました。

  • 事例や活用方法まで深堀りした勉強を十分にできていない。
  • サービスそれぞれの理解もまだ浅い。
  • ネットワークの基礎ができていない。

ためか、適切な組み合わせがわからないのだろうと思いました。

そもそも、speciality試験に該当する一般知識（ANSの場合はネットワーク知識）を持っている前提でないと、speciality試験はキツイ気がしてきました。

今後はどうする？

ANS再リベンジはします。ただ、2週間経ったらすぐ再受験はしません。 焦らずに一度立ち止まって、これまで学んだことを深掘り、理解を固めてから再挑戦しようと思います。

10月にデータベーススペシャリスト（デスペ）受験予定なのでそれまでにやるか、 Database - Specialityを一緒に勉強して先にそちらを受けようかとも考えています。 ネットワークの勉強は続けますが、ANSリベンジにこだわりすぎずに距離を置くのもいいかもしれません。

最後に

全体的に認定合格を意識した勉強になりすぎていたかなと思いました。 AWS認定を通して技術の勉強をする良い機会にはなっていますが、 良い仕事をするために必要なのはAWS認定だけでは決してないので、 ANS合格を焦りすぎず、他のことにももっと視野を広げようと思っています。

合格体験記として書ければ良かったのですが、この不合格体験記がこれからANS-C01を受ける人の参考にほんの少しでもなれば幸いです。

最後までお読みいただき、ありがとうございました！

Cloudflare Meetup Tokyo Kick Off !! 参加レポート

Cloudflare 勉強会レポート

はじめに

4/25、「Cloudflare Meetup Tokyo Kick Off !!」に参加しましたので、レポートを書きます。

はじめてのCloudflareの勉強会、ワクワクしながら参加しました。

cfm-cts.connpass.com

はじめてのCloudflare 高速化とセキュリティの両方を行うために　Cloudflareエバンジェリスト 亀田治伸さん

資料

公開されたらURLを追記します。

概要

  • Cloudflareのビジョン
    • インターネットの高速化とセキュリティの維持
    • 安全性、信頼性とパフォーマンス、高速性の両立
  • 世界のインターネットトラフィックの全体20%を支える。
    • 分散エッジデータセンタで様々な処理をしている。
  • Cloudflareはキャッシュを使わなくてもCloudflareを通す。
    • HTTPS
    • L3/L4
      • エニーキャストルーティング
      • インターネット上の輻輳遅延を回避している。
    • SaaS
      • クライアント常駐アプリが通信を保護
      • 不正なドメインへのアクセス回避

所感

「Cloudflareという企業、サービスを初めて知ることができた！」そう感じたセッションでした。 特に、インターネットを安全なものにというCloudflareのビジョンには共感するばかりでした。ユーザを大事にしてサービスを良くしようという思想にも驚きました。

インターネットが出て20年以上、生活は便利になったと思いますが、一方でサイバー攻撃には悩まされるばかりです。 それを懸念してインターネット、クラウドサービスを使うことに臆病になる人は多いはず。 こういった人たちに貢献しているんだと思い、一気に好印象を持ちました！

CloudflareのPages/Workersとは？　森茂洋さん

資料

speakerdeck.com

概要

  • Cloudflare Workers

    • エッジ環境で動作するWebAPIをデプロイできる。
    • オリジンサーバに近いエッジでレスポンスを返す。
    • JavaScriptで動作する。コールドスタートは0ミリsecと言われている。
    • Workers KV,R2などのデータストレージと連携

  • Cloudflare Pages

    • GIt ベースのデプロイワークフローを持つ
    • Jamstackサイトを構築し、Cloudflare のCDNにホスティング
    • Pages Functions
      • フロントエンド開発者のためのフルスタックプラットフォーム

所感

今回、Cloudflareにはどんなサービスがあるのか、ハンズオンで使うサービスは何か、まったく知らない状態で参加しましたので、 ハンズオンで使うサービスを話していただけたことには本当に感謝です。ハンズオンが楽しみになりました。

作ったサーバレスWebアプリケーションを手早く公開するのに、とても便利なサービスだと思いました。 自分はWebアプリケーションをまともに作ったことはありませんが、この２つのサービスを使って簡単なものでもWebアプリケーションを公開してみたい、チャレンジしてみたいと思いました。

あの頃数百自治体のコロナワクチン 予約フォームを救ったWaiting Roomの運用　武田可帆里さん

資料

speakerdeck.com

概要

  • Logoフォームについて
    • 自治体が、簡単にノーコード、ローコードで電子申請などをできるサービス
    • リリース当初からCloudflareを導入
  • リリース後に出てきたコロナワクチン予約
    • Logoフォームの問い合わせが殺到した。
    • クラスメソッドさんがCloudflare Waiting Roomを無償提供
  • Waiting Roomとは？
    • デジタル待合室を用意し、順番が来たら自動的にフォームに遷移する。
    • キャッシュをユニークユーザとして認識する。
    • Cloudflare内で設定された待ち行列アルゴリズムで待ち時間を予測する。
  • 困ったことと工夫したこと
    • 同時アクセス時の時間
      • 導入した自治体から実績をとって事例を説明した。
    • 設定値の最適地がわからず異常な待ち時間で不満につながるリスク
      • サーバの負荷をみながら最適値を見つけた。
    • 予約の不公平さが発生
      • 予約を開始した時点で待合室を有効に。
    • APIを経由してSlackで待合室発動と行列に並んだ人数を通知

所感

アクセス集中するフォームへの待ち行列を作ることができるサービスを知らなかったので、Waiting Roomはとても面白いサービスだなと思いました。

アクセス集中していてもちゃんとつながっていて順番になったら案内されることが分かる、それだけでもユーザとしてはとても安心感があると思います。 面白いサービスと思ったと同時に、ユーザにやさしいサービスだなぁと思いました。

お話しいただいた通り、実際に導入すると運用するのは大変だと思いますが、Waiting Roomのイメージを掴むことができてとても良いセッションでした！！

ハンズオン　新居田晃史さん

以下の手順を基に実施しました（アカウントは、勉強会参加前に事前に作成しました）。

①Cloudflareアカウント新規登録

zenn.dev

② Cloudflare 開発ツール Wranglerの設定

zenn.dev

③Cloudflare Workers と KV でTodoListアプリを作る

zenn.dev

完全にはじめて使うサービス、ドキドキしながらハンズオンに臨みました。この感覚すごく良いです♪

Cloudflareの操作に慣れてないためか手間取り、時間内にハンズオンが終了しませんでした。早く完走したかったので、帰宅後寝る前に続きをやって無事終了しました。 WorkersとPages、KVについて全体感を知ることができましたが、復習のためにも時間を空けてもう一度ハンズオンをやってみようと思います。自分なりのカスタマイズもできないかを考えながら。

亀田さんが執筆したZennの記事は上記2,3以外にも公開されていましたので、そちらも読んで実践してみようと思いました。

最後に

Cloudflareについてはほとんど知識がない状態での参加でしたが、企業としてのCloudflare、サービスとしてのCloudflareについて少しでも知ることができ、 両側面からもっとCloudflareを知りたいと思えました。とても楽しく学びの多い勉強会でした。

まだまだ知らないことばかりなので、今後のCloudflareの勉強会にも積極的に参加していきたいです。

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

勉強会レポート AWS

目次

はじめに

4/14（金）JAWS-UG朝会 #44に参加しました。 毎月恒例の朝会、今日も参加レポートを書きます。

イベントページ

jawsug-asa.connpass.com

セッションとLTの概要と所感

セッション① CICDを使用したECS Blue Greenデプロイを実施する際に必要なファイルについて takashiさん

CICDで必要なファイル

  • buildspec.yml
    • CodeBuildで使う。
  • appspec.yml
    • CodeDeployで使う
  • taskdef.json
  • imageDetail.json
    • ECSイメージURIが記載されているJSON。

buildspec.yml

  • pre_buildフェーズ
    • imageをプッシュするECRにログインしている。
    • imageタグをビルドの実行IDを指定している。
  • buildフェーズ
    • ビルド環境でimageをビルド
    • ビルドしたImageを参照して、ECRにプッシュsるためのimageを作成している。
  • post_buildフェーズ
    • ECRにビルドしたimageをプッシュ
    • ECRにデプロイする際に使用するImageURIを記載してImageDetail.jsonファイルを作成する。
  • artifacts
    • post_buildで精製したImageDetail.jsonをCodeBuildのoutputとして定義。

buildspec.yml

  • TargetService
  • TaskDefinition
  • ContainerName
  • ConteinerPort

taskdef.json

  • image
    • ECRにプッシュしたImageを使用するため、"<IMAGE1_NAME>"を記載。
    • ECSで現在使用しているタスク定義の最新のリビジョンのjsonを基に作成している。

CodePipelineの設定値

資料

公開され次第追記。

所感

Codeシリーズは普段あまり使わないけど、Codeシリーズ4つともガッツリ使ったら面白そうですね。使う機会があったら、お話しいただいたことを思い出して活かしたいと思います。

セッション② Amazon VPC Lattice触ってみた！ SREホールディングス　釜田康平さん

Amazon VPC Latticeとは

  • アプリケーションサービス間通信のためのネットワークを抽象化したサービス。
  • VPC間のアプリケーション通信のために接続する場合、以下を利用してサービス間通信を制御することも可能に。
    • ServiceNetwork
    • Service
    • Target Group

構成要素

  • ServiceNetwork
    • 論理的なアプリケーション層ネットワーク
    • 紐づけたVPC内のクライアントは、DNS経由でサービスネットワーク内のサービスを自動検出できる。
  • Sevice
    • ALBに似た要素
    • Listener,Ruleを設定する。
  • Rule
    • Serviceに来た通信のルーティングを設定する。
  • TargetGroup
    • ルーティングするターゲットをまとめたもの。
    • EC2,IPアドレス,Lambda関数、ALBを指定できる。

WorkShop

catalog.us-east-1.prod.workshops.aws

  • Lattice設定辞意ルーティングテーブルの編集はしていないのに、Client側からService側へアクセスできている。
  • 送信元VPCサブネットに紐づくルーティングテーブルにリンクローカル用のルールが勝手に追加されている。

資料

speakerdeck.com

所感

Amazon VPC Lattice、どんなサービスか追えていないので、お話聞けて良かったです。 まずは触ってみるところから！ハンズオンを後日やってみます！！

※ハンズオン catalog.us-east-1.prod.workshops.aws

LT① チョットワカル！〜SIEM on Amazon OpenSearch Service〜　株式会社セゾン情報システムズ 山口大輝さん

  • 複数のログを相関分析し、一括で横断して検索できる。
    • IPをキーにGuardDutyログやCloudTrailログなどを一画面に表示できる。

  • グラフで可視化できる。

  • 仕組み

    • SIEM on Amazon OpenSearch Serviceをプロビジョニングしたアカウントのログ集約バケット（S3）に様々なところからログを集約。
    • Lambdaで加工・取り込み、OpenSearchで分析。
  • 作成方法
    • AWSアカウントへログインした状態で、GitHubページのLaunch Stackボタン押下後、約30分で作成可能。

資料

speakerdeck.com

所感

SIEM on Amazon OpenSearch Serviceのハンズオン、時間がかかりそうだったので、ずっとやろうと思っていて腰が重くなっていました。これも後日。今度こそやります！！

※ハンズオン catalog.us-east-1.prod.workshops.aws

LT② AWS Glue Data Quality 触ってみた　NRIネットコム 高梨友之さん

  • AWS Glue Data Qualityとは？
    • re:Invent2022で発表されたサービス。
    • データソースのデータが、こちらの意図したものになっているかどうかを自動チェックする機能。
    • チェックしたい条件を「ルールセット」として登録して、データソース内のデータを対象に評価を行う。
    • 保存済データを基にAWS側が児童で生成してくれる「Recommend ruleset」機能もあり。
    • CloudWatchメトリクスもパブリッシュしてくれる。
    • 対象データソースは今のところS3のみ。
    • 日々取得する多くのデータソースの質を担保でき、手間いらずでデータレイクの品質がアップ。
    • 専用チェックルールを定義し、ETL処理のテスト実施にも利用可能。

資料

公開され次第追記。

所感

AWS Glue Data Qualityも全然追えていなかったので、これもお話聞けて本当に良かったです！ re:Invent2022で発表されたサービス、ほとんど追えてないことを実感。。。 新しいサービスやアップデートも出来る限り確認しないとなぁ。。。

LT③ Amazon QuickSightを使ってみて、ハマったこと/Tips集　スターフェスティバル株式会社 山﨑皓平さん

1. テキストボックスの背景色を変更できない。

  • シートレイアウトを「タイル」から「フリーフォーム」に変更することで、背景を変更可能。

2. RLSを有効化したデータセットを複製できない。

  • ユーザーベースRLS（行レベルセキュリティ）を有効化したデータセットを複製できない。
    • 調べたけど複製できなかった。
    • タグベースRLSの場合は複製できる。

3. タグベースのRLSを有効化しても、分析画面でデータを表示する方法

  • ユーザーベースRLSで、QuickSightユーザーに参照権限付与すると、分析結果からデータ参照できる。

4. カスタムSQLを設定したデータセットを別のユーザに共有する。

  • データソースにも権限付与する必要がある。

資料とブログ

speakerdeck.com

zenn.dev

所感

Amazon QuickSight、設定が複雑そうですね…実運用で使うと大変になりそう（汗

まだまだ触れていないですが、いつか絶対に使ってみたいサービスだと思っています。 その時は参考にさせていただきます。こうやって、ハマったことやTipsを公開いただけるのも本当にありがたいです。

最後に

VPC LatticeとGlue Data Quality、新しいサービスのことほとんど確認できていなかったので、お話聞けたのは本当に良かったです。でも、誰かが話してくれるのを待つばかりでなく、もっと自発的に新しいサービスに触れてアウトプットしなければ…と思いました。

やっぱり何にせよ、触る⇒知見を得る⇒アウトプット するのが一番ですね。

最後まで読んでいただき、ありがとうございました。

ssmonline #34 参加レポート

勉強会レポート

目次

はじめに

4/13（木） ssmjp に参加しました。久々のssmjpで久々にガッツリと運用を勉強できたと思えた回でした。 セッションの概要と感想を書いていきます。

イベントページ

ssmjp.connpass.com

セッション概要と所感

継続的に技術書を読む習慣について @nlog2n2さん

習慣

  • 本屋に通う
    • 文章、書き手との相性を確認するために。
    • 時間を忘れてたら（2分）買う以外選択肢はない。
  • 本を買う
    • とにかく買う、積む、値段は見ない。
    • 薄めの本を書う。
    • オライリー本は買って損はない。
    • 読めなかったときは、本を譲ることも頭の片隅に入れておく。
  • 本を読む
    • 隙間時間に読む。
    • 仕事にして読む。
    • しおりと付箋を活用する。
    • 積んでるものを洗い出して、TodoやWBSを引く。デッドラインを設定する。
    • 自分の読める力量（1時間当たりの読めるページ数、読み切れるページ数）を把握しておく。

おススメの本

ハッキングAPI ―Web APIを攻撃から守るためのテスト技法 | Corey Ball, 石川 朝久, 北原 憲, 洲崎 俊 |本 | 通販 | Amazon

PMBOK対応 童話でわかるプロジェクトマネジメント［第2版］ | 飯田剛弘 |本 | 通販 | Amazon

きれいなPythonプログラミング ~クリーンなコードを書くための最適な方法 | Al Sweigart, 岡田佑一 |本 | 通販 | Amazon

所感

最近ようやく本屋に行きやすくなったので、本屋に行って買うか、本屋で下見してからAmazonでポチるかをやる習慣が戻ってきました。 技術書もビジネス書も決して安くないので買うの迷いますが、読めそう！と思ったら買った方がイイですね！（限度はあると思いますが…） 自分はなかなか集中して読書出来る方ではないので、WBSにする、デッドラインの設定はやってみようと思いました！

「ハッキングAPI」、読んでみたい！なかなかのお値段（汗

お話いただいたように、本屋さんに行って立ち読みして2分以上読むことができたら買います！！

運用の範囲(運用設計入門コース)　波田野さん

運用の範囲

  • ドキュメントを整備出来ない、運用でカバーをさせられる、評価されないのは、運用の業務範囲が不明瞭だから。
  • 運用設計においては業務範囲の定義が不可欠。
    • 効果的に高い評価を得るため。
    • 専門性、成長ロードマップが曖昧になり、人材が育たない。パフォーマンスが下がる。
    • 不要不急な業務が増え、必要な業務を圧迫するようになる。
  • 運用の範囲において専門性を発揮するのが運用組織。
    • 運用の専門性＝範囲 を明確にし、人的リソースを効果的なものにして高い評価を得る。

運用の専門性

  • 事業継続のための専門性
  • 事業継続を支える専門性
    • ネットワーク、サーバ、ソフトウェア、セキュリティなどの技術
  • 専門家の原則（組織構造の設計５原則より）
    • 運用組織と業務は運用のための知識、技術、経験によって構成されている。

業務のグレーゾーン

  • 運用業務に「設計されていない業務」が存在している異常状態
    • 業務範囲を明確にしても、環境の変化でグレーゾーンが発生する。
    • グレーゾーンの放置は、あらゆる「運用あるある」を生み出す。
    • グレーゾーンには3種類ある。
  • ニューホワイトゾーン(ホワイトゾーンよりのグレーゾーン）
    • 運用上の課題や新たな需要の発見、運用現場へのチャンスにつながる宝の山。
  • ダークゾーン（ブラックゾーン寄りのグレーゾーン）
    • 現場リソースを過剰に消費したり、法令・規約違反を含むこともあるブラックゾーンの候補でリスクの山。
  • テンポラリーゾーン（白でも黒でもない中間のグレーゾーン）
    • 最もパターンも発生件数も多いため、発生する前提で運用設計を行う。
    • 発生状況や発生形態を把握し全体レビューをする。
    • 期間と範囲を限定してテンポラリーゾーンを受け入れる仕組みを整備する。
    • 発生したまま放置しないこと。

所感

「業務範囲の定義」、できていない個所があると気づいたり、

「ドキュメント化できないのは業務範囲が曖昧だから」、この言葉に思い当たるフシがたくさんあって恥ずかしくなりました。。。

誰かに自分の業務を知ってもらいたい、巻き取ってもらいたいならば、まずはその範囲を定義をすること。でないと、関わる人に大変な思いをさせてしまう。グレーゾーン解消の優先度上げないと…

今回も学びが多いお話でしたが、自分の業務に関する運用の不備や至らないところを猛省するばかりでした。

このようなお話を頻繁にしていただけて、波田野さんには感謝です。

継続的コミュニティマネジメントとアウトプット 〜大切にしてきたこと、成功、失敗〜 (ssmjp編) 　吉江さん

アウトプットしないのは知的な便秘精神

知識創造企業 | 郁次郎, 野中, 弘高, 竹内, 勝博, 梅本 |本 | 通販 | Amazon

※新装版もありました。 知識創造企業(新装版) | 野中 郁次郎, 竹内 弘高, 梅本 勝博 |本 | 通販 | Amazon

コミュニティの参加・運営

  • JAWS DAYS 2013に参加。
  • OWASP Japan PR Teamに参加してアウトプットする意義を知った。
  • Security JAWS を立ち上げ運営に参加
    • 以降、JAWSのイベントや支部の立ち上げ参加など。
  • 運営メンバの支えがあって同じ目標を目指すことができた。

継続的コミュニティマネジメント

  • 意味のある価値を生み出す中心となりたい。
  • 有意義な共同作業をしたいという欲求の高まり。
  • 立ち位置の確認。
継続コミュニティマネジメント
1. P-MVV
  • Purpose(Why 存在意義)
  • Mission(What 使命)
  • Vision(Where 将来像)

  • Value(How 大切な価値観・方法)

  • 継続的「意味のある価値」の醸成。

  • 他コミュニティイベントへの参加を推奨し、得た経験をふりかえる。
2. フォロー
  • アクセスへのリーチのフォロー、アクセス後のアフターフォロー
    • コミュニティへの継続参加を促す。
    • 学びと経験のアウトプット
3. コミュニティマーケティング
  • 自走する組織
  • 勉強会の継続開催
  • 巻き込み力で新たな人間関係、信頼作り。
    • 新たなアイディアを取り込む。
    • 巻き込まれた人にチャンスを作る。インサイドアウトのキッカケに。
4. ブランディング
  • 独自性の追求

  • インナーブランディングとアウターブランディング

    • JAWS-UGでアウトプットする人はこれらが自然とできている。

  • フィードバックとフューチャーワーク

  • やったことの結果、外向けにはどう映った？ふりかえりが必要。 　- アンケート回収率向上は未だに課題。
6. アウトプット
  • 勉強会の経験から得た学びを表現や活動に反映させる。
  • アウトプットしないのは知的な便秘
7. ソーシャルキャピタル
  • 目に見えない価値、つながりの力
  • コミュニティや個人にとって、繰り返し蓄積することが重要。
  • 活動する場と幅を広げる。意識空間の方を広げる。
    • 場：活躍する活動空間
    • 幅：活躍する意識空間
一期一会
  • 一瞬を大切にし、一期一会で終わらせない。
  • 今経験していることは二度と起こらない
  • オファーから始まるチャンスを手繰り寄せる。断るのは簡単、オファーされるのは難しい。
  • 自分が得意としないイベントへの参加と経験は、インサイドアウト、マインドチェンジにつながる。
推薦図書

遠くへ行きたければ、みんなで行け ~「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 | ジョノ・ベーコン, 山形 浩生, 関 治之, 高須 正和, 山形 浩生 |本 | 通販 | Amazon

手にとるようにわかる ブランディング入門 | 金子大貴, 一色俊慶 | 産業研究 | Kindleストア | Amazon

もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら | 岩崎 夏海 | ビジネス・経済 | Kindleストア | Amazon

資料

docs.google.com

speakerdeck.com

所感

コミュニティ運営をするのは大変だけど、主体的に考えて活動することで多くの経験を得られて楽しそうだと思ったのが第一印象でした。 自分は今は一般参加側の方が多いですが、コミュニティに一般参加することも意義のある活動だと思っています。 それをもっと意義のある活動として、まずできることはやはりアウトプットだなと思いました。最近サボってましたが、これが今日ブログを書いたキッカケです。 このキッカケを新しいつながり、新しい知見を発見したり、新しい活動の一端にできればなぁと思いますし、この記事が誰かの何かのきっかけになることを願っています。

取り急ぎ、吉江さんの推薦図書「遠くへいきたければ、みんなで行け」と冒頭紹介いただいた「知識創造企業」を、Amazonでポチリました。 本当は先の @nlog2n2さん のお話にあったように、本屋に行って相性確かめてからにしようと思いましたけど…居ても立っても居られず。

最後に

本の読み方のヒント、運用設計における業務範囲の定義、コミュニティの運営と、内容も濃くてあっという間の2時間でした。 読みたい本も増え、早速買いました。届いたら少しずつ自分の読める範囲で継続的に読んでいこうと思います！

思えば、自分が勉強会コミュニティに参加するようになったのは、ssmjpがはじめてでした。 今日の勉強会が終わって初心に帰れた気持ちでした。

やはり、アウトプットしないのは知的な便秘ですね！！

JAWS-UG千葉支部オンライン#20 -AWSではじめるクラウドセキュリティ- 参加レポート

AWS 勉強会レポート

目次

はじめに

2023/3/23 JAWS-UG千葉支部オンライン#20 に参加しましたので、参加レポートを書きます。

今回は、「AWSではじめるクラウドセキュリティ」をテーマのイベント、書籍を読んで予習をしてから参加です。

※手前味噌で恐縮ですが、昨日自分が書いた書籍の感想ブログを載せます。こちらも見ていただけますと幸いです。

amarelo24.hatenablog.com

セッション

「AWSではじめるクラウドセキュリティ」をはじめてみよう 松本 照吾さん

概要

  • セキュリティに興味がある職員が集まって書いた書籍。これからITをクラウドを学ぶ人への架け橋にという想いで書いた。
  • セキュリティが課題になった時の議論をするための土台になれば。
  • 技術はたんにその知識を得るだけでは使いこなせるようにはならない。実際に触って体験し、ときには失敗することで身に付いていく。
  • 「何のためにセキュリティが必要なのか」を考えると、ビジネス上の期待や要求などとのバランスを取ることが必要。
  • セキュリティはビジネスを安全に回すための手段
  • 「サービスは何のためのものなのか」、「何のためそのセキュリティ対策が必要なのか」を考える。
  • 先に過度に細かいルールを増やしてしまうと、新たな変化に対してブロッカーになってしまうリスクがある。
  • セキュリティの原則に立ち戻り「そもそも何を実現したいのか」という視点を持つことが重要

所感

mentiを使って参加型のセッションで楽しみながら拝聴できました。 その一方で首がもげそうなくらい同感できる言葉が多く、WHATとWHYを大事にして人にやさしいセキュリティ対策をしたいと思いました。

Security Lakeの話の続編 山口 隆史さん

概要

  • セキュリティ対応の背景は、情報収集の自動化と定期的なスキャンと対策

    • Security Hubの指摘を確認してトリアージしていたが使いづらい…

  • 理想の運用

    • セキュリティベースライン評価を少ない工数で実施できる
    • すべてのアカウントのリスクの状況が一覧で確認できる

  • Security Lakeを使った解決策

    • 数ステップでセキュリティデータを自動的に一元化
    • Security Hubに保存したデータを正規化した形でS3にエクスポートできる
      • Athenaでクエリ出来る
      • QuickSightで集計できる

  • 課題

    • リソースを例外にするのにマネコンでの作業が必要
    • Remediationの確認がSecurity Lakeの情報だけだと不十分
    • 新規の指摘かどうか確認できない

  • 用法と料金に注意してSecurity Lakeを活用しよう

    • 検知だけして満足しない、修復するまでが運用
    • 運用を楽にするには継続した改善活動が必要

所感

最後の「修復するまでが運用」、これが一番大事だと思います。 脆弱性を残したままではなく、修復するか問題ないことの確証を得る。ここまでやらないと不十分だと思います。 そのためには、運用に負荷をかけすぎずに、省力化できるところは改善して力を入れるべきところに集中する。少しずつでもこれを実現したいと思います。

Security Lakeも使ってみたいです。

「AWSではじめるクラウドセキュリティ」感想LT1 北原 雅人さん

概要

  • セキュリティの基本を学ぶ上で基礎が図解付きでまとめられており、非常に読みやすい
  • 索引からも振り返りがしやすい
  • AWSの詳細は深く掘りさげず、ポイントとしてどのサービスを利用したらよいか理解できる。
  • セキュリティはサービスの中心ではない
  • 脆弱性は人から生まれやすい
  • ガードレール型の検知を推奨
    • 効果的に利用できるためにも積極的な利用を
  • クラウド運用におけるセキュリティの意識ポイント
    • 風通しの良いセキュリティ文化
    • インシデントレスポンスの訓練
      • 定期的な訓練とフィードバック
    • インシデントレスポンスの自動化
      • 自動化、IT化できるところは積極的に進めるべき

所感

書籍に対する感想は、自分も同感です。セキュリティ対策の効果を上げるためにも、ガードレール型セキュリティ、インシデントレスポンスの自動化、文化の醸成、どれももっと取り入れたくなりました！

「AWSではじめるクラウドセキュリティ」感想LT2 山口 正徳さん

資料

https://speakerdeck.com/kinunori/chiba-cloud-security-special

概要

  • 情報セキュリティの３要素のうち最も重要な要素は何かを考える。
    • Availability（可用性）を考えて、それぞれの最適解を導く必要がある。
  • 守るべき対象がサービスを提供する理由は？
    • セキュリティが優先された結果、そのサービスが存在する理由を失ってはいけない。
  • 「AWSではじめるクラウドセキュリティ」は基本を知ってから実践に入れて構成が良い。

所感

情報セキュリティを考えるとどうしても機密性や完全性に偏りがちなところがありますが、 サービスの足を引っ張らないためには可用性を損ねてはいけないと思います。 もちろん可用性優先でもダメですが、それに陥らないよう、知識を身に付けて実践し、自らアウトプットする。 それを繰り返して自分もサービスも成長させねばなぁと思いました。心に刻みます！

「AWSではじめるクラウドセキュリティ」感想LT3 和田 健一郎さん

概要

  • 非常に読みやすかった。
  • 某ロボットアニメで起こったインシデントに想いを馳せながら読んだ。
  • 「セキュリティとは？」から始まって、AWSのセキュリティ、ハンズオンと勉強になった。

所感

セキュリティを知ってしまうと、マンガやアニメの一シーンに「あれ、これマズいんじゃね？」と思うことが目についてしまいますねｗ いいか悪いかは置いといて…

普段の業務外からもセキュリティの重要さに想いを馳せられるようになれば、気づきも多く得られそうだと思いました。 色々なことに積極的に目を向けたいし、もっとセキュリティも勉強しないとなぁ。

「AWSではじめるクラウドセキュリティ」感想LT4 榎本 ジョン 航介さん

概要

  • 最近流行りのアイツにセキュリティについて聞いてみた。

    • アクセス制御の強化
    • 暗号化
    • 監視
    • セキュリティポリシを作る
    • クラウドプロバイダーの評価

  • 「AWSではじめるクラウドセキュリティ」で答え合わせしてみた。

    • 書籍に、AWSのサービス、責任共有モデル、クラウドベンダに任せるといった観点が触れられていた。
    • セキュリティの基本から入る書籍なので初心者にも読みやすい。

所感

最近流行りのアイツ、賢いですねwww（自分も使いたいのですが、まだ手が出ない…）

セキュリティの基本から入っている書籍なので、セキュリティやっている人もそうでない人も読みやすく、勉強のし直し、気づきの発見もある本だなぁと読んでて思いました。事あるごとに読み返したくなりそうだなぁと思います。

最後に

前回もそうでしたが、課題図書があると予習をして参加できるので、参加の熱量が上がります。 勉強会当日の登壇を拝聴して学びになる事はもちろんたくさんありますが、読書会形式だと予習したことの認識合わせ、自分にない観点を得ることができるので、学びも刺激も多く理解が深まると思いました。自分にはとても合っていて、予習から勉強会終了まで楽しく集中して取り組むことができました。

書籍は一通り読みましたが、あと残課題としてハンズオンをやるのみ！ここで得た知見もアウトプットできれば（できたら…）と思います。時間がかかりそうなので、まとまった時間を確保してやります。早くやりたい！！