クラウドでうまく安全に作る話 #SecHack365

クラウドでうまく安全に作る話 SecHack365 開発駆動コース 仲山 昌宏 （@nekoruri）

仲山 昌宏 / @nekoruri • クラウドなんでも屋さん • SecHack365 トレーナー （2017-） • LayerX （2022-） • 技術系同人誌サークル 「めもおきば」「ssmjp同人部」 • #ssmjp / #qpstudy /#serverlessjp • Microsoft MVP (Azure, Cloud Native) モデム • ProjectSEKAI Rank.385 2

Security Hackathon 365 • 作りたいものを完全に作り切るには1年は短すぎる • 自分が作りたい部分に「特に」注力する • 全体イベントを軸に高速にフィードバックを回す • 6回の全体イベント、もう2回目 • MVP：Minimum Viable Product モデム

クラウドサービス活用を前提とした開発 • よくできた部品を使う • 内部でライブラリを利用してカスタマイズ ⇒ 外部クラウドサービスを設定して連携する • 自分で作りたい部分「以外」に自分の時間を使わない • 自分のモチベーションの向き先を自覚してコントロールしよう • 作りたい部分は作っていい モデム • あとから興味がわいて作りたくなることもあるよね

よく使われるやつら • 認証 ⇒ Amazon Cognito、Auth0、Firebase • データベース ⇒ TiDB Serverless、Neon、Firebase、Supabase • KVS ⇒ Amazon DynamoDB、Azure Cosmos DB • キャッシュ ⇒ momento、Upstash • ファイル置き場 ⇒ Amazon S3、Azure BLOB Storage、Cloudflare R2 • コンテナ実行 ⇒ Google Cloud Run、AWS App Runner、Azure Container Apps • アプリ実行 ⇒ AWS Lambda、Azure Functions、Cloudflare Workers • メール送受信 ⇒ Amazon SES、SendGrid • 監視・Observability ⇒ Datadog、New Relic モデム • CI/CD ⇒ GitHub Actions

サーバーレス 「サーバー」の抽象化によって登場した以下の性質をもつサービス 1. 運用者：自分でサーバーを管理しなくて良い • 完全従量課金（※）なフルマネージドサービス • 0円から使った分だけいくらでもスケールしてくれる 2. 開発者：個々のサーバーに依存する機能を利用しない • プロセスメモリやファイルシステムはリクエストをまたいで 共有されない（ことがある） モデム • レプリケーションとシャーディングによるスケーラビリティ確保 ※ 最低限動かし続けなくてはいけない動作（に対する課金）はありうる 6

サーバーレス（別解） momento社による定義 • サーバーレスの真の定義で、 偽サーバーレス賊を撃退する ⇔ NISTのクラウド定義 • オンデマンド・セルフサービス • 幅広いネットワークアクセス • リソースの共用 • スピーディな拡張性 • サービスが計測可能 モデム

• https://jp.gomomento.com/blog/fighting-off-fake-serverless-bandits-with-the-true-definition-of-serverless/

「サーバーレス」の全体像 イベントバス・ワークフローエンジン 小さな計測単位：時間、性能 サーバーマシン管理からの解放 確保量から使用量へ 弾力性 （オートスケール、ゼロスケール） 完全従量料金 フルマネージドサービス オーケストレーション・コレオグラフィ ID管理・認証認可 マイクロサービス・分散システム イベントドリブンアーキテクチャ リアクティブシステム リソースの抽象化 microVM/コンテナランタイム アクターモデル スタートアップの高速化 プログラミングモデル サーバーマシン依存リソースの非共有 プロセスメモリ・ファイルシステム シャーディング・レプリケーション ストリーミング処理 価値への注力 抽象化のグラデーション Container – Function – DSL - Configuration 8

個人開発とサーバーレス • 完全従量課金のサービスを選ぼう • 「サーバーレス」と名乗っていても最低利用額がそれなりのものがある • 小さな計測単位のサービスを選ぼう • AWS Lambda、Azure Functions：実行ミリ秒×メモリ量 • Momento：オペレーション数 • DynamoDB、TiDB Serverless：処理別に設定されたユニット数 モデム

Kubernetes • Kubernetes（k8s） • YAMLによる宣言型定義とReconciliation Loop • Cloud Controller Managerによるクラウドサービス管理 • 可搬性（ほかの場所にもっていって動かす） ⇔ クラウドサービス活用 • 大規模を「想定」したものを作るなら選択肢に入ってくる • もちろんk8sの技術スタックそのものもおもしろい モデム

迷ったら • コンテナと相性の良い言語（Golang等） • Google Cloud Run、AWS App Runner、 Azure Container Apps • スクリプト系言語 • FaaS: AWS Lambda、Azure Functions、Cloudflare Workers • Buildpacksでさくっとコンテナ化するのも有効 モデム • Next.jsならVercelもあり

分散システムとしての難しさ • マイクロサービスの組み合わせ = 分散システム • 「分散コンピューティングの落とし穴」 • Wikipedia: 分散コンピューティングの落とし穴 • ネットワークは信頼できる。 • レイテンシはゼロである。 • 帯域幅は無限である。 • ネットワークはセキュアである。 モデム • ネットワーク構成は変化せず一定で ある。 • 管理者は1人である。 • トランスポートコストはゼロである。 • ネットワークは均質である。

• https://ja.wikipedia.org/wiki/分散コンピューティングの落とし穴

その他よく言われるデメリット • 学習コスト • 使ってみる程度でそこまで難しいものはめったにないのでがんばれ • ベンダーロックイン • 開発生産性を上げて開発速度で殴れ • マルチクラウド モデム • よくある話「ほとんどAWS上にあるけど分析だけGoogle BigQuery」

普段から道具の「素振り」をしよう • 手札を増やす ⇒ 「いつも使うサービス」 • 気になるサービスは、まず1時間Quick Startを素振りしよう • すぐ使えるか、結構大変か、を知っておく • 使い方を知っておくと、あらかじめそれに寄せた設計ができる モデム • 作りたいものに注力して作っていこう

最初からセキュアにつくる • 性善説ノーガードが許されるのはローカル環境だけ • 証明書のCTログ ⇒ Let’s Encryptした瞬間にアクセスが飛んでくる • インターネットに公開した瞬間からセキュアに • IPアドレス制限やCloudflare Accessなどでデフォルト閉じておく • VPSや仮想サーバでもSSH等を安易に開けない ⇒ AWS Session Manager、Cloudflare Tunnel経由 ⇒ コンテナやFaaSの利用も検討しよう モデム

まずCI/CDとIaCを組もう • もう作り始めている人は、今回のイベント中に、CI/CDを整備しよう • 泥臭くてもダサくてもよいので、まずやろう、今すぐやろう • とりあえずGitHub Actionsにスクリプトべた書きやブログ記事コピペでもOK • ウェブサービスならデプロイまで、ソフトウェアならいったんビルドまで • テストも書こう • スモークテスト：起動するかや基本機能などを簡易的に確認する • テストやlinterを育てよう モデム • GitHub Dependabotなどで依存先のアップデート対応

まずCI/CDとIaCを組もう • IaC（Infrastructure as Code）も組もう • クラウドサービス管理のIaCは人道的に必要（Ansibleとかはまた別の話） • AWSならCDK、AzureならBicepがファーストチョイス • それ以外はTerraformかPulumiの記述法が好きなほうで • ただし学習コストが決して低くない • WebUIとかCLIからいじって試行錯誤してからでいいのでIaC化しよう • 最初は、IaCツールでなくCLIコマンド羅列のスクリプトでもいいから書こう モデム • WebUIとかが裏でやってくれている操作を含めて定義が必要 • はやめに「苦労」しておいたほうが有利

最小権限原則の徹底 • 前提：クレデンシャル（「キー」等）を直接つかわない • 動的な権限付与のしくみを必ず使う • サービス間は仮想マシンや関数アプリへのロール割り当て • GitHub ActionsからはOIDC認証 • ロールに対して最小限必要な権限を付与 • 使う権限だけを割り当てる（ドキュメントを引く癖をつけよう） • コントロールプレーンとデータプレーンを意識 モデム • 最低でも操作単位（s3:GetObject等）、慣れてきたらリソース単位で許可

設定の適切さを管理 • よくある事例 • S3に置かれたバックアップデータに外部からアクセスできていた • ハードコードされた認証情報の漏洩、悪用 • CI/CDが持つ（サービス構成変更可能な）つよつよ権限奪取 モデム

設定の適切さを管理 • 設定もまた重要な「コード」のひとつ • 汎用⇔特化のグラデーション Container – Function – DSL - Configuration • 使うべきものを適切に使う • S3パブリックアクセスブロック • AWS Secret Manager、Azure Key Vault • CDだけに環境（コントロールプレーン）を操作させる モデム • 緊急時のためのbreaking glass（参考事例：CrowdStrike障害）

設定の適切さを管理 • 予防的ガードレール、発見的ガードレール • ポリシーでできることを制限する（AWS SCP、Azure Policy等） • 不適切な設定の検知・通知（CSPM） • 膨大な設定項目をすべて適切か判断するのは無理 ⇒ 検出項目の標準セットがある • AWS Foundational Security Best Practices (FSBP) • Microsoft クラウド セキュリティ ベンチマーク (MCSB) モデム • CIS Benchmarks

ベストプラクティスを知る • Well-Architected Framework • クラウドベンダーが提供するベストプラクティスのセット • AWS Well-Architected • Azure Well-Architected Framework • Google Cloud アーキテクチャ フレームワーク モデム

• https://aws.amazon.com/jp/architecture/well-architected/
• https://learn.microsoft.com/ja-jp/azure/well-architected/
• https://cloud.google.com/architecture/framework?hl=ja

ここまでのまとめ • 短い1年間で作りたいものを作ろう • そうでない部分はクラウドサービスの力を借りる • 使える道具を増やしておこう • 最初からセキュアに • いますぐCI/CDとIaC • 最小権限原則 • 設定をコードとして管理 モデム • ベストプラクティスを知る

ぷちLT • 推しのクラウドサービス もしくは • 使ってみたいクラウドサービス • ひとり1分ずつ • TypeTalk でタグにぶら下げていってください モデム