AWS Summit Online2021 しょぼ感想
大した内容じゃないけどせっかくだから書き残そうかな程度の話です
このブログ読むより当該セッション見たほうがいいよ。見れるのかわからんけど...
以下セッションを見た
- AWS Lambda を攻撃してみた ~サーバレスのセキュリティの考え方~（パートナーセッション）
- インフラエンジニアだけでサービス開発してみた～フルスタックエンジニア育成への取り組み～（パートナーセッション）
- リモートワークを実現した中堅中小企業が語る導入前と後の実際のところ-中堅中小企業にとっての働き改革とは- (CUS-26)
- ZOZOTOWNにおけるAmazon EKSを中心に据えたマイクロサービスアーキテクチャへの変遷(CUS-01)
- Amazon CodeGuru ～機械学習で実現するコードレビュー自動化とアプリケーションパフォーマンス最適化～(AWS-02)
AWS Lambda を攻撃してみた ~サーバレスのセキュリティの考え方~（パートナーセッション）
セッションの内容
Lambdaはマネージドサービス。ユーザ側が気にしなくてはいけないことは
- コードのセキュリティ
- 機密データの管理
- 認証認可
- モニタリングやログ記録
Lambdaのセキュリティ的な観点からみた特徴としては
- イベントソースが多い
- HTTP API, Message Que, CloudDB, IoT Device
- それぞれが攻撃の対象になりうる
- HTTP API, Message Que, CloudDB, IoT Device
- システム設計が複雑になる
- モジュールの構成管理が複雑
- インシデント・レスポンスのための可視化・検知が困難
- セキュリティテストだけでは不十分
- 構成が複雑で本番環境を複製しにくかったりも
リスクが予想しにくいことが一番のリスク
リスクの発生頻度と影響度が予想しにくいため負けない設計が重要
→リスクを予測して対応するより設計にセキュリティを組み込むことが大切
攻撃ゼロではなく被害ゼロを目指す
侵入を前提としたセキュリティ設計。各レイヤで防御すること
WAF(Botブロック)-API Gateway(匿名遮断)-Function(RASP)
境界防御(企業内NWは安全とみなす)のみではなくゼロトラストで内部を守ろう
トレンドマイクロはCloudOneという製品を出してるよ～～～
→ 僕の個人開発ではお金をかけられないのでスルー
感想
REST以外のアクセスしか想定してないからイベントソースについては気にしたことなかったかも
システム設計が複雑になるってのは確かに身に沁みて感じるところで、どっかで設定漏れがあったりしそうで怖いなと思う
レイヤ防御、監視について、取り敢えず作ってから考える。みたいなことが多い(当社比)けど、構築前からもっとしっかり考えていかないと穴作りそう
あと最近はクレデンシャルを盗むのが流行ってるらしい
とツイッターで書いてたら
クレデンシャル，結局は実行プロセスの環境変数に埋まっているので，何らかの方法で任意のコマンドを実行できたら流出しますね（env 叩けさえすれば盗めちゃう）
CI は実行ログをユーザに見せるので， CI にそういう脆弱性が埋まってたら終わり
とか教えてもらえました
調べてたらここらへんが参考になった
www.slideshare.net
インフラエンジニアだけでサービス開発してみた～フルスタックエンジニア育成への取り組み～（パートナーセッション）
セッションの内容
資料を載せてるひとがいたのでそれ見るとわかりやすい
全部のってるわけじゃないよ
AWS Summit Japan | インフラエンジニアだけでサービス開発してみた～フルスタックエンジニア育成への取り組み～（パートナーセッション）｜hase / 長谷川 正雄｜note
社内インフラエンジニアを集めて社員向けAWS学習サイトを開発したよ。という話
サイトの中身はAWSの学習的なやつ。資格勉強用の選択問題とか社内講演の動画視聴とか
構築は
- Amplify + React
- Serverless
あとはサイト構築にまつわる体験や苦労などの話
経験者が少ない中、興味をもった社員に参画してもらってメンバーを増やしていった...とかそういう話
感想
それぞれについては既にぼんやり理解したつもりになっていたので実務的なサーバ構成の再確認的ができてよかった
AWS AppSync(GraphQL)のことは知らなかったので勉強しないといけない...
あとAWSのWorking Backwordsって文化があるみたいでその話も面白かった
【レポート】『「あなたのお客様は誰ですか？」から始まるAmazonのイノベーションのメカニズム、その手法をハンズオン』を受けてきた #AWSSummit | DevelopersIO
すごいざっくり言うとAWS流の「お客様への価値提供を見直してみよう」手法の話
この話は事業部長ポジの人とかに共有したら覚えが良さそう
サイト構築というか社員に参画してもらってたような部分について言うと、社内でこういった文化があるのは羨ましい
大企業ならでは？大企業だと逆にやりにくかったりしないのだろうか？
リモートワークを実現した中堅中小企業が語る導入前と後の実際のところ-中堅中小企業にとっての働き改革とは- (CUS-26)
セッションの内容
省略...
感想
AmazonWorkSpacesというもののご紹介がメインだった
https://aws.amazon.com/jp/workspaces/
シンクラ的に仮想デスクトップを使えるというもの
初期の手間がかからず比較的安いのが良さそう
AWSでAD作ってるとより連携便利だとか
VPNより手間かからなそうなのがいいね
ただ接続料従量課金以外にも固定費がかかるのがネック
スポット利用で従量課金のみだと嬉しいんだけど
このセッションを見て思ったけど、「リモートワーク環境を作りたい」と言われた時に自分がやると即答できるくらいの技術的引き出しとリテラシないとダサいと思う
「もし自分が情シスだったら？」というような仮定で、自分が実際やるかどうかはさておき
ZOZOTOWNにおけるAmazon EKSを中心に据えたマイクロサービスアーキテクチャへの変遷 (CUS-01)
セッションの内容
省略...
感想
ClassicASPで組んだモノリシックなWebアプリケーションをマイクロサービスアーキテクチャにするという話
カビたような技術に親近感を感じたくないけど親近感を感じますね～涙
僕が常々「段階的移行せえ！」と唱えている仕組みがストラングラーパターンと呼ばれていることを知った（言葉が分かると知識を深めやすく便利） https://www.atmarkit.co.jp/ait/articles/2001/23/news003.html
その他セッションではアーキテクチャの要点が紹介されてて参考になるだろう
僕はまだEKSがまるで分かっていないので資料だけ落としていつか読むということで...
あとZOZOではAPI Gatewayを内製して色々機能盛ってるらしい。すごい！
Amazon CodeGuru ～機械学習で実現するコードレビュー自動化とアプリケーションパフォーマンス最適化～(AWS-02)
セッションの内容
省略...
感想
CodeGuruはCodeGuru ReviwerとProfilerの二つに分かれる
それぞれ概要はこんな感じ。他のサイト見たほうがいいよ！
- Review
- コードレビューするやつ
- PRに組み込みこんだりできる
- 発火タイミングはいろいろ
- いまのところJava, Pytyon(Beta)
- Profiler
どっちも既存のCI/CDに統合しやすいよ！というのが売りみたい
Reviewはまあそのまま役に立ちそう
PRに毎回指摘が出てくると面倒くさそうではあるが触ってみたい
Profilerは便利そうだけど使い所が難しい？ずっと走らせておくWebアプリケーションで使えるのかこれは？？？
起動 - E2E - 終了みたいな感じにユーザ動作を想定したシナリオを通じたパフォーマンス取得とかはいけるかも
Profilerのその他の使いどころを考える
LambdaでがっつりJavaってパターンは正直無い気がしていて、Pythonの場合も計測するほどの処理をしない場合が多いと思う
と思うとJava/JVM言語でバッチ書く時くらいにしか役立たない？
とはいえどっちにしても料金の問題があるので個人使用はないかな。無料期間はありつつも...
私事だけど転職する時にやたら「パフォーマンスチューニングの経験は？」と聞かれ「ないですが興味あります」からのお祈りパターンを受けまくった
※僕のように薄給で働く人間はそんな高級なことはなかなかできない。大概、事業の売上向上施策の工数に割り当てられる歯車の一つに過ぎないからだ
そういうことを思うと、気軽にパフォーマンスチューニングやった感出せるこのサービスは良いものかもしれない
