amareloのブログ(仮)

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

AWSではじめるクラウドセキュリティ 読後レポート

目次

はじめに

AWSではじめるクラウドセキュリティ」を購入して読みましたので、読後レポートを書こうと思います。 この書籍はAWS社の職員の方々が執筆した書籍ですが、AWSに特化した記述だけでなく、 情報セキュリティとは何か、セキュリティを守るための組織の在り方が示されていました。

これまでの知識の見直しになったのと同時に一方、現状不十分 or できていないこともあり、 セキュリティ担当者の方でもセキュリティの学びと実践には終わりはないことを再認識しました。

以下自分が学びと感じた点と所感を書いていきます。 第3部(第10章と11章)のハンズオンは、執筆時点でまだハンズオン完了していないため、第1部と2部が対象となります(完了次第別記事で気づきや学びを書いていこうと思います)。

明らかな誤認識などがありましたら、ご指摘いただけますと幸いです。

なお、本記事については私個人の見解であり、組織を代表するものではありません。

セキュリティはサービスの中心ではない

第1章からの引用です。 確かにどんなサービスも、セキュリティが主役ではなく、ユーザがサービスに対して感じる価値もセキュリティではありません。 書籍でも書かれているような、知識やスキル不足、負荷とそこに対するリソース配分が課題になっているからだと思いますが、 ここに気付いておきながら、手間を増やしてしまう(or 本来不要なことをやり続けている)ことは結構あるんではないかと思いました。 逆に手間を減らしてしまう(or 必要な対策を適切にとらない)こともあるのではと思いました。

バランスを取るのは難しいことですが、 サービス運営、サービスに関わる人に手間を与えてしまったり、逆に脆弱性を作ってしまうと、その分サービスの価値を落としかねません。 対策の本質を見極め、相手に対する価値やメリットを提示できるよう頭を働かせないと、所属組織の対外的価値も落としてしまいかねないと思いました。 常に考えながら取り組まなければならないと思いました。

WHYとWHATとHOW

第2章からの引用ですが、「はじめに」にも書かれていました。

  • 何が期待されているか(WHYやWHAT)
  • どのように実現するか(HOW)

また、それに対する、

  • 説明責任(WHY/WHAT)
  • 実行責任(HOW)

を実行しなければなりません。説明責任はアウトソースできないですが、これは経営者だけでなく現場の担当者にも言えることかなと思います。 また、実行責任をアウトソースできても、そこに対する統制はしなければなりませんし、アウトソース先にやってもらうことの理解がないと、対策は破綻してしまうと思います。 自分が何の対策をして(どこにアウトソースを依頼して)、なぜやるのか、自分以外の人たちに説明できるように。まずはそこからかなと。 対策の効果を上げられるよう、HOWとWHYとWHAT、心に刻んで仕事しようと思いました。 セキュリティに限った話でなく、当たり前のことかもしれませんが…

ガードレール型のセキュリティ

第4章と第8章で触れられていました。 組織にガバナンスとポリシーを定めないと、人による脆弱性が生まれます。 人的ミスを防ぐためのITによる仕組みも、ただ使うのではなく統制が必要です。 しかし、「統制」ばかりすると、手間を増やし事業やサービスの邪魔になってしまうかもしれません。

歩みを止めず道を外さないように進んでもらい、逸脱を発見できるようにするガードレール。 変化のスピードが激しい現代、このアプローチによる対策をいかに考えられるかが大事だと思います。 とはいえ、ガードレールがあればゲートキーパーは不要かと言ったらそうではなく、 ゲートキーパーで防げない物をガードレールで検知できるようにすることが必要。 これも、WHYとWHATを明確にして、どのポイントでどう守るか(HOW)を定義すれば、 手間になりすぎず脆弱性を作りこむことも少なくなるのではないかと思いました。

データフローによる保護範囲の把握

第6章からの抜粋です。個人的にはここが今までにない観点で、これを意識したアセスメントができていなかったため取り上げました。 Webシステムのデータフローが例として挙げられていましたが、システム以外にも業務フローにも当てはまることかと思います。 データの流れ、仕事の流れに着目すれば、暗号化されていない個所、盗聴されかねない場所、老朽化したネットワーク、人的ミスなど、 不足している対策が見えてくるということに改めて気づかされました。何事も流れをつかむことが大事ですね。

最後に

冒頭に書いた通り、「AWSではじめる」と銘打ってあるものの、AWSに特化しているわけでなく、 他のクラウドサービスに置き換えても共通する内容だと思いました。 AWSをはじめクラウドに関わりの浅い情報システム担当者や企業の情報セキュリティ部門の方々が読んでも 学びになること、見直しになることが多いのではないかと思いました。

セキュリティ管理、監視と検知の一般的な考え方とAWSでの実現方法が絶妙なバランスで書かれていたため、 「このAWSサービスはどんなシーンで使われるのか」についても、とても分かりやすかったです。 AWSを活用してセキュリティ対策をしたい方にもうってつけと思いました。

明日3/23に以下のイベントがありますので、今回のブログを書いて予習になり、少し頭を整理できて良かったと思っています。 まだまだ理解が浅いと思っているので、明日のイベントに参加して、事あるごとに読み返して理解を深めていきたいです。

jawsug-chiba.connpass.com

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

はじめに

1/17 JAWS-UG朝会 #41 に参加しましたので、まとめを書きます。

目次

セッション① RDS/Auroraバージョンアップのポイント hmatsu47(まつ)さん

自分はデータベースのバージョンアップをしたことはないですが、ポイントを抑えることができる内容で分かりやすかったです。 やはりデータベースのバージョンアップや移行は考えることが多くて大変と思いますし、DBを担当されている方々には頭が上がらない思いです。

データ移行時の考慮ポイント

重視するポイントはバージョンアップ対象ごとに異なる。v1からv3へのバージョンアップは避ける。

  • ①データ完全性
  • ②機能の互換性
    • バージョンアップ前後で動作する仕様に
  • ③性能
    • オプティマイザヒントの使い方は事前に調べておくこと
    • 事前の性能テストは重要
  • ④停止時間
  • ⑤切り戻し

手法

  • ①インプレースアップグレード
    • 既存DBとクラスタをそのままバージョンアップ
  • ②クローン後にインプレースアップグレード
  • ③ブルーグリーンデプロイ
    • 旧バージョンのDBからコピーしたDBをアップグレードし、旧DBから新DB間レプリケーションする。
    • データ不整合の可能性がある。
    • PosgreSQL系の場合は論理レプリケーションのためDDLがほぼ使えない。
  • ④アプリケーションを改修後新旧DBへの同時並行書き込み
    • 無停止でバージョンアップが実現可能だが、アプリケーション実装の手間がかかる。
    • 書き込み処理時間が延びる。

計画進行のポイント

組織体制やバージョンアップ対象に適した計画を。

  • ①作業分担と協力体制
  • ②情報共有
    • フィードバックを集めて生かす。理解可能な形で共有。
  • ③事前準備
    • リハーサルを何度も実施すること。一度では気づかないバグもある。

資料

speakerdeck.com

セッション② EC2にてDisk枯渇が発生した場合に何が起きるのかと対応方法 ハンズラボ株式会社 中川皓紘さん

個人でAWSを使っているだけだとディスク枯渇のことあまり考えないけど、 業務で使う場合は考えないとならないですね。よい気づきになりましたし面白かったです! 自分もちょっと試してみようと思いました。

障害対応フローを再現

  • Disk枯渇状態にする。
  • 再起動して起動不可になることを確認(セッションマネージャで接続できない)
  • Disk枯渇状態のEC2からEBSをデタッチして、復旧用EC2にアタッチして起動する。
  • 新規でアタッチしたEBSはマウントされていないので、マウントする必要がある。
    • DiskのUUIDが重複してマウント不可になるが、一時的なマウントなのでUUIDの競合を無視してマウントする。
  • ファイル削除して残容量が危険域を脱したらもとのEC2に再度アタッチする。

  • Amazon Linux2の場合はディスク拡張しても、パーティションをコマンドで作らなければならない。

資料

speakerdeck.com

LT① Amazon Forecast を使って売上予測をしてみた 株式会社モリサワ 小室貴史さん

AL/MLのサービスはまだまだ勉強不足なので、やってみた内容のLTは全体感を知れて有り難いです。 自分がコーヒー売ることになったら使ってみたいなw

  • Amazon Forecastはマネージドな時系列なデータ予測サービス
  • データセットが準備されているのでAL/MLを知らなくても使えるが、用語を調べたり専門的知識はあった方が良い。
  • 売り上げ予測で試してみる。
    • DBかCSV取得しS3に保管。Forcastで分析してQuickSightで可視化した。
    • 休日データがノイズになって予測にズレが出た。
  • データ量が少ないといい結果が出てこない。
  • 費用はそこそこかかる。

資料

speakerdeck.com

LT② 統合CloudWatchエージェントとCloudWatch Logs エージェントの違いを深掘ってみた クラスメソッド株式会社 おつまみさん

CloudWatch エージェントは「統合CloudWatchエージェント」の方しか知らなかったです。 旧があったことも初めて知れて、新旧を比較することでバージョンアップで便利になって今があることを再認識出来て良かったです。

  • CloudWatchエージェントとは?
    • EC2からログやメトリックスを収集するためのエージェント
  • CloudWatch Logs エージェント
    • 廃止予定
    • ログのみ収集
      • メトリックスはカスタムスクリプトでCloudWatchにアップロードする必要がある。
    • Linux系のみでオンプレ未対応
  • 統合CloudWatch エージェント
    • ログとメトリクスを収集
    • 複数プラットフォームに対応可能。オンプレも対応。
    • SystemsManagerによる設定が可能。

資料

dev.classmethod.jp

LT③ Transit Gateway(TGW)利用時における専用サブネットの必要性 積田 優生さん

去年Transit Gatewayのハンズオンをやった時は、ENIとEC2別々のサブネットになっていました。 公式ハンズオンでバットプラクティスにすることはないとはいえ、なぜそうなっているのかは意識していませんでした。 その意味を知れてできてよかったですし、ハンズオンの構成もなぜこうしているのかを意識することで学びの質が変わると実感しました。

  • Transit Gateway ENIとEC2を同じサブネットに置く(バットプラクティス)
    • EC2は、配置されたTransit Gatewayサブネットのルートテーブルを参照する。
      • EC2の意図するルートテーブルが作れなくなるため、EC2から直接アクセスさせたい先へのルートを通せなくなる。
        • /24でネットワーク設計していた場合は、IPアドレスが無駄になってしまう。
  • Transit Gateway ENI専用サブネットを作成し、EC2は別のサブネットに置く(ベストプラクティス)
  • 必須ではないが、影響を理解していないのであれば、TGWアタッチメント専用サブネットを作った方が良い。

資料

speakerdeck.com

zenn.dev

最後に

今年はじめの朝会、新たな学びと気づきがあって濃い内容でした。 それにしても、ラジオ体操を毎月やるたびに肩の鳴りが増えている気がする…

2023年の目標

目次

はじめに

2023年になりました。あけましておめでとうございます! 去年は目標を書いていませんでしたので、今年は目標を書きます。

2022年のふりかえり

AWS認定への挑戦はし続けて前年以上の結果を出せました。

しかし、アウトプット量は減り、仕事への向き合い方にも疑問を感じるようになりました。 結果的にアウトプット前提のインプットにならず、本質的な理解が不十分だったと感じています。 良かったこともありましたが、やり切った感触は少なかった1年でした。

良かった点

  • AWS認定3つ合格(SCS・SOA・SAP)
  • Coffee Advent Calendar 最高寄稿者更新

足りなかったこと

  • 情報処理技術者試験不合格(春秋ともに)だった。
  • 挑戦的な仕事をなかなかできなかった。
  • 今の仕事を続けることに疑問を感じるようになったが、どうありたいか言語化できなかった。
  • 登壇、ブログなどアウトプット量が前年(2021年)と比べて減った。
  • コーヒーを広めるための活動がほとんどできなかった。

2023年の目標

  • 職種・職場・働き方を変える(※)。
  • コーヒーを職場に広める。
  • コーヒーのイベントを開催する。
  • コーヒー好きな人を最低1人増やす。
  • ネットワークスペシャリストデータベーススペシャリストに再挑戦する。
  • AWS認定に3つ(ANS・DBS・DAS)挑戦する。
  • オフライン勉強会で最低3回登壇する(技術ネタ云々は問わず)。
  • 関東圏外のオフライン勉強会に最低1回は参加する。
  • 技術ブログを最低月1回のペースで書く。

「自己を見直す」が今年のテーマだと考えています。 新しい仕事への挑戦とスキルアップ、コーヒーを広めるための挑戦とその環境作りを図りたい。 また、より多くの人たちと知り合って知見を広め、出会った人たちに何かを良い影響を与えられるようなアウトプットをしたい。 そのためにも、これまでの自分の行動、考え方、仕事、環境等を見直して、変えられるところを変えていきたいと考えています。

最後に

長々と書いても仕方ないので、簡単に書きました。 1月に誕生日を迎えてまた一つ年を取ります。 自分ももう若くないけど、様々な立場、年齢の方が挑戦しているのを見ていると、諦めたり気後れするのはまだ早い。 向き不向きは置いといて、今までやってこなかったことに「挑戦」して自分の殻を破りたいと考えています。

あまり気負いしすぎない程度で楽しくやっていきたいですが、1つでも多くの結果を出したいと思います。

ペルー マチュピチュ

12月25日ですが、この記事は、Coffee Advent Carendar 2022 第24日目の記事として投稿させていただきます。

※空いてたので投稿させていただきました。

adventar.org

最近お気に入りの豆を紹介です。

ペルー マチュピチュ

www.coffee-rc.jp

世界遺産であるマチュピチュ遺跡と同じ名前。生産国が分かりやすくて良いですね♪

※参考:マチュピチュ遺跡

www.his-j.com

自分は中煎りと深煎りの両方焙煎しています。

中煎りはスッキリした酸味と甘味、 深煎りはキレがある苦味で、 どちらもお気に入りの味です。

マチュピチュ遺跡のように壮大なイメージに合う豆だと思います。

見かけたらぜひお試しください!!

ダム際でコーヒーを

目次

初めに

この記事は、Coffee Advent Carendar 2022 第1日目の記事です。

adventar.org

毎年恒例のCoffee Advent Carendarがはじまりました。 初日は私amarelo(アマレロ)が書きます。

「1人でどこか気の向くままに出かけてのんびりしたい。」

ある日の仕事中、ストレスが溜まっていたのか、急にそんな思いが湧いてきました。

たまには自分だけのために休暇を取って気晴らしした方が良いと思い、以前からやってみたかったダム巡りに行こうと思いました。

そこでコーヒー淹れて飲んだらのんびりできて気持ちいいだろうなぁと思い、9月と10月にダム際コーヒーをやってきました。

2022/9/9 群馬県みなかみ町 藤原ダム

藤原ダムについて。 www.ktr.mlit.go.jp

9月前半の日中帯はまだ暑いと思い、自宅でアイスコーヒーを淹れて持っていきました。 ダム湖を眺めながらアイスコーヒー、はじめてのダム際コーヒー。広大なダム湖と自然を眺めて癒されました♪

ダムからの帰りに立ち寄った川のほとりでもう一杯。

ダム際ではないですが、水上駅から上越線土合駅に行き、駅舎内にある駅茶モグラにてもう一杯アイスコーヒーをいただきました。 土合駅は別名モグラ駅ともいわれており、地下ホームから地上までの階段は486段強! 疲れましたが、その疲れた体に染み渡るアイスコーヒーでした。アンバタートーストも美味しかった♪

2022/10/14 埼玉県秩父市 浦山ダム

浦山ダムについて

ja.wikipedia.org

情報処理技術者試験が終わって間もないころだったので、気分転換しようと思い行ってきました。 この日は朝からあいにくの雨。浦山ダム到着時も雨で霧がかかっていましたが、幻想的な風景に見えて心躍りました♪

先に昼食を済ませて雨脚が弱まってきたところを見計らって、ダム際でコーヒーを飲みました。 雨の予報だったので、この日はホットコーヒーを自宅で淹れてきました。 山に軽く霧がかかった景色を見ながら飲むコーヒー。なかなかできない景色と経験でした。

午後に差し掛かって雨は完全に止んだので、天端のベンチで読書をしてから帰りました。 浦山ダムは天端が広く、のんびりコーヒー飲んだり読書するにはうってつけの場所だと思いました。 2週間くらい前に行っていたら、紅葉がキレイだっただろうなぁと思います。行けばよかったなぁ。。。

最後に

自然の中でのんびりとコーヒーを飲みながら読書をし、ダムのある町を観光して過ごす休日。

家にばかり居続けるのにも疲れが出てきたので、景色を変えることで良い気分転換になり気持ちよく過ごすことができました。 また、今回のようにコーヒーの楽しみ方を実践と追及して発信していくのは、コーヒーを広めるための活動の一つだなと思いました。 車は使えなかったので公共交通機関を使っていきましたが、小旅行のような感覚も味わえたのも良かったです。 スケジュールを調整して定期的にダム巡りとダム際コーヒーをやり続けたいと思います!

短いですが、今日はここまでにします。最後まで読んでいただきありがとうございました!!

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

3か月ぶりの更新になってしまいました。ブログ書けなくなっていましたが、少しずつ書いていこうと思います。

本題です。11/9、自分の中では毎月恒例になったJAWS-UG朝会 に参加しました。

先月先々月は参加してたものの書けませんでしたが、今月はようやく書けました。

目次

イベントページ

jawsug-asa.connpass.com

セッション内容

(今更ながら)AWSのコンテナサービスについてざっくりまとめてみる クラスメソッド株式会社 つくぼしさん

コンテナとは?

  • アプリケーションのコード、構成、依存関係を単一のオブジェクトにパッケージ化する(AWS公式より)
  • chrootがコンテナの元祖と思われる。
  • 仮想ファイルシステムの分離をできるpivot_rootが登場し、その後Dockerが登場。
  • つまりコンテナとは、高機能な仮想ファイルシステム
  • コンテナレジストリ
  • コンテナオーケストレーション
    • 複数のサーバを麻袋でコンテナを管理する機能
    • 一部のサーバが停止した際にコンテナを別サーバで再起動する。

AWSのコンテナ主要サービス

  • Amazon ECR
    • AWSが提供するマネージドプライベートコンテナレジストリサービス
    • アクセスにはAWSの認証情報が必要
    • ECSやIAM等の連携が容易
    • 自前でプライベートコンテナレジストリを運用する必要がない。
  • Amazon ECR Public
    • マネージドパブリックコンテナレジストリサービス
    • AWS認証情報なしでアクセス可能。
    • イメージPull回数制限がない。
    • Docker Hubの代替手段として利用できる。
  • Amazon ECS
  • Amazon EKS
  • AWS Fargate
    • コンテナ用のサーバ管理が不要な起動タイプ
    • クラスタ基盤であるEC2を運用する必要がない。
    • 一部機能制限がある。

AWSのコンテナ関連サービス

  • AWS App Runner
    • マネージドコンテナデプロイサービス
    • コンテナイメージURI、サービス名、CPUメモリ、ポート番号を指定するだけでデプロイ可能。
  • AWS Proton
    • デプロイワークフローツール
    • インフラ基盤担当とアプリ担当に分かれて、コンテナ基盤を柔軟に運用できる。
  • AWS Copilot
    • ECSを構築するための専用CLIツール
  • AWS Cloud Map
    • マネージドサービスディス賀張サービス
  • AWS App Mesh
    • マネージドサービスメッシュサービス

資料

speakerdeck.com

セッション② 企業のシステム棚卸業務にSSM Inventoryで挑む カスタムインベントリの全て 株式会社ビックツリーテクノロジーコンサルティング 熊谷 有輝子さん

構成管理とは

  • システムを提供運用するために必要な物理資産の状態や文書を人が確認できるように管理すること。

SSM Inventoryとは

  • OS上のアプリ一覧など構成情報を記録
  • 可視化のための簡易的なダッシュボード機能を提供
  • 標準インベントリでアプリケーション、AWSコンポーネント、ファイルなどの情報を取得
  • マルチアカウント構成下でのインベントリ情報も収集可能

カスタムインベントリ

  • 取得できる情報
    • オンプレミスのサーバラック位置に関する情報
    • オープンソースAPI利用有無
    • 所定のファイルパスは以下にカスタムインベントリとして収集したい情報をJSONに記載したものを置く。
  • JSONファイルの情報は定期的に更新しなければならない。

SSM State Managerを用いた構成管理

  • 定義された状態にサーバを保つプロセスを自動化する。
  • サーバの状態を確認、是正するための定期的な処理に向く。
  • 定義したスクリプトを所定の時間に実行
  • スクリプトをSSM Documentとして管理できる。
    • SSM Custom Documentの作成
    • スクリプトの作成
      • カスタムインベントとして収集したい情報を作成する。
    • Associationの作成

カスタムインベントリ機能の制約

  • マルチアカウントの横断分析はSystems Managerではなく、Athena,QuickSightで確認する必要がある。

資料

speakerdeck.com

LT① 定期バージョンアップ、私の苦手な言葉です。(EKS/Aurora編) KDDI 御田 稔さん

  • Amazon EKS

    • EKSのアップデートサイクルが12か月間サポートに変更。
    • 半年に1回くらいはバージョンアップしたいところ。
    • 機能増減や仕様変更も激しい。
    • リリースは、ブルーグリーンデプロイで新規クラスタに移行。
      • DNS切り替えだけでなく、ELBのターゲットグループの付け替えで切り替えするシステムもある。
  • Amazon Aurora

    • メジャーバージョンは3年ごと。マイナーバージョンアップは1年ごとを目安に更新したいところ。
    • 普段やってる開発タイミングを見計らって検証してもらえるよう、アップデート計画を立てている。
    • 事前にスナップショットを取ってバックアップしておき、インプレースで更新する。
    • マイナーパッチングでブルーグリーンデプロイしている人がいるか気になるので、他の人の事例も知りたい。

資料

speakerdeck.com

LT② JAWS DAYS 2022にボランティアスタッフとして初参戦してみました クラスメソッド株式会社 あしさん

  • 会社のSlackチャンネルの投稿を見て、何も分からないけど応募した。
  • 動画配信のオペレーションを担当した。
    • 配信画面の切り替え、幕間動画の切り替えなど
  • オフラインで参加して良かったこと
    • イベントの熱気を身をもって体感できた
    • 登壇者の話を至近距離で聞くことができる。
    • イベントの一部になれた。
    • オフラインならではの出会いがあった
      • 双方向かつ偶然のコミュニケーション
      • 配信担当、打ち上げで一緒になった人と仲良くなれる。
    • お世話になったJAWS-UGに貢献できた。
  • 学びの方程式
    • 興味、義務、情熱、これらを掛け合わせたものがっけか
    • コミュニティ登壇や運営はこれに当てはまるのでは?

資料

公開されたことを確認出来たら追記します。

LT③ Lambda拡張機能を使ってLambdaパフォーマンスを上げよう BeeX 那須 隆さん

  • Systems Manager Parameter Storeからのパラメータや、Secrets Managerのシークレットを取得するレイテンシとコストを削減でき、アプリケーションのパフォーマンスを向上できるようになった。
  • 計測してみた。
    • SDKで取得と比較すると、半分以下の時間で済んだ。
  • APIリクエスト回数の上限がある。
    • Parameter Store:40TPS(スループット制限の上限緩和可能)
    • Secrets Manager:5000TPS(上限緩和不可能)

資料

speakerdeck.com

最後に

コンテナ何もわからなかったので、コンテナのお話は凄くしっくりきました。分かりやすかったです。SSMについても資格試験勉強している者としては、とても参考になるお話でした。

ボランティアスタッフ参加のお話では、またオフラインイベント参加したい気持ちにさせられました。オフラインイベントのボランティアスタッフや運営は、人見知りコミュ障の自分はどうしても二の足踏んでしまいますが、機会を作って挑戦してみたいと思いました。

今回は以上になります。ありがとうございました!

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

久々のブログになってしまいました。 8/4 JAWS-UG朝会 #36 に参加しましたのでレポートを書きます。

目次

イベントページ

https://jawsug-asa.connpass.com/event/245634/

セッション内容

セッション① AWSのコンテナイメージスキャン手法をまとめてみた クラスメソッド株式会社 たかくにさん

コンテナセキュリティ

  • ECRイメージスキャン(ベーシックスキャン)
    • 手動スキャン(24時間に1回)と自動スキャン
    • Clair プロジェクトのデータベースを使ってスキャン
    • 無料
    • 導入しやすい
  • ECRイメージスキャン(拡張スキャン)
    • Inspectorがサービスロールを使ってスキャン
    • 複数のデータベース(Snykなど)を使用
      • Snykのデータベースの一部を使っている
      • 有料
    • OSに加えてプログラミング言語パッケージもスキャン対象
    • Security Hub、Organizationsとの統合
  • docker scan
    • docker-scan-pluginを使ってローカルのDockerイメージに対して行うスキャン
    • Snykを使用
      • Snykとは
        • 開発者が利用するために作られたセキュリティプラットフォーム
    • 無料
  • Docker Hub上で脆弱性スキャン
    • 有料
  • Snyk Container
    • Snykデータベースを使用
    • OSに加えてプログラミング言語パッケージもスキャン対象
    • 日次や週次の定期スキャン
    • 新しいCVEが公開されたら自動でスキャン
    • 無料プラン(100回/月)と有料プランがある

資料

speakerdeck.com

セッション② インフラのテストにVPC Reachability Analyzer は外せないという話 株式会社ヌーラボ 中野雅之さん

ネットワーク疎通テスト

  • 手動でやるとサーバ増えた時に無理
  • ツールに頼る必要がある

Serverspecとawspec

  • Serverspecとは?
    • Ruby製のOSS
    • サーバのプロビジョニング状態やネットワークレベルの疎通確認ができる。
  • awspecとは?
    • AWSリソースに対する設定のテストができる
  • 気になる点
    • コンテナやALBを起点とした場合の確認は?
    • VPC Reachabbility Analyzerの使用

VPC Reachabbility Analyzer

  • AWSリソースに対するネットワークレベルの疎通テストを行うことができる
  • ただ、一度作成したパスは編集ができないので再作成する必要がある
  • ECS FargateのようなENIがコロコロ変わるリソースとは相性が悪い
    • ENIのタグ名がコンソール上では表示されないのでわかりづらい
    • AWS CLIを使う
  • Serverspecやawspecを併用して手厚いテストを実施可能

資料

speakerdeck.com

LT① シェルスクリプトAWSをいい感じに使いたい shimoさん

  • シェルスクリプトを使ってAWS操作を自動化
    • 覚えることが減る
    • 時短できる
    • オレオレ魔改造になりがちになる
  • EC2インスタンスSSH接続
    • VPC接続を確認
    • 複数EC2から選択
    • EC2を起動してIPを受け取る
      • start-instancesで起動
      • 出力は 2 > $1 > /dev/null で捨てる
    • SSHログインする
  • これらを順番に.shファイルに書いていけば出来上がり

資料

docs.google.com

LT② サーバレス開発が地味にキツイ、特にDynamoDB NTT東日本 長久保聡さん

  • 仕様変更や機能追加の時にきつくなる
  • GSIを安易に付与するとテーブル設計が崩壊する。引継ぎが辛くなる。
    • RDBみたいな構造になっていく
  • scanはscan全体で課金される。
  • マイクロサービスが上手く構築されていないのが原因

資料

※公開され次第追記

LT③ 年700万円損するサーバレスの認可システムをご紹介します!! 生活協同組合コープさっぽろ 樋口修也さん

  • 認証認可とは?
    • 認証:端末の使用者が誰かを明確にする
    • 認可:誰に何をして良いかを確認する
  • 複数APIあるとレガシーidの管理が大変
  • 認可用のAPIを作るとアクセスが集中してコストと保守工数が発生してしまう
  • Auth0上のmetadataにレガシーidを持たせる
    • 複数APIもOK
    • id変更も一括で可能
  • トークンの認可を各APIで処理するとお得になる

資料

speakerdeck.com

最後に

DynamoDBのscanはDB全体へのスキャンにお金がかかること、初めて知りました。 自分が作ったTwitter BotでDynamoDB Scan使っているので、レコード増やし過ぎないように気をつけなければと思いました。 AWS CLIシェルスクリプトの活用、まだまだやれていないことあるので、今日シェルスクリプトの話を聞けて刺激になりました。

最近ブログ更新出来ていませんでした。勉強会には色々参加しているんですが、サボり癖がついて良くないですね。。。アウトプット大事! 朝会の登壇も希望者が増えてきて内容が濃くなったので、自分が登壇する時ももっと内容と精度を高められるようにしなければ。。。