Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWS Keymanagement Serviceを知ろう
Search
MATSUURA, yosuke
June 07, 2020
Programming
0
680
AWS Keymanagement Serviceを知ろう
AWS KMSとは何か、何に使うのかということを説明した資料です。
※身内でやった勉強会の資料から内輪ネタを削ったものです。
MATSUURA, yosuke
June 07, 2020
Tweet
Share
More Decks by MATSUURA, yosuke
See All by MATSUURA, yosuke
CircleCIとSchemaSpyを使ったMySQLドキュメントの自動生成
bateleurx
1
930
WebRTC配信システムをAWSからオンプレミスに切り替えている話
bateleurx
14
13k
機密情報をKMS+RDS,S3とParameter Storeを使って保存した話
bateleurx
0
3.3k
VAddy導入案内
bateleurx
0
280
0から始まるかもしれない固定長整数をINT型に入れたい
bateleurx
0
1.9k
Other Decks in Programming
See All in Programming
私はどうやって技術力を上げたのか
yusukebe
43
17k
Le côté obscur des IA génératives
pascallemerrer
0
120
クラシルを支える技術と組織
rakutek
0
190
非同期jobをtransaction内で 呼ぶなよ!絶対に呼ぶなよ!
alstrocrack
0
540
猫と暮らすネットワークカメラ生活🐈 ~Vision frameworkでペットを愛でよう~ / iOSDC Japan 2025
yutailang0119
0
220
CSC305 Lecture 02
javiergs
PRO
1
260
複雑化したリポジトリをなんとかした話 pipenvからuvによるモノレポ構成への移行
satoshi256kbyte
1
790
開発者への寄付をアプリ内課金として実装する時の気の使いどころ
ski
0
350
CSC305 Lecture 01
javiergs
PRO
1
400
株式会社 Sun terras カンパニーデック
sunterras
0
230
開発生産性を上げるための生成AI活用術
starfish719
1
170
LLMとPlaywright/reg-suitを活用した jQueryリファクタリングの実際
kinocoboy2
4
670
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
We Have a Design System, Now What?
morganepeng
53
7.8k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
960
Designing Experiences People Love
moore
142
24k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
A designer walks into a library…
pauljervisheath
209
24k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
The Pragmatic Product Professional
lauravandoore
36
6.9k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
Transcript
AWS Key Management Service(KMS)を知ろう
共通鍵によるデータの暗号化 • 共通鍵暗号は256bit AESがデファクトスタンダード • 安全な暗号とはアルゴリズムが公開されていて、脆弱性が見つかって いないこと • 厳密に言えばAESは高性能な量子コンピュータに対して脆弱だが、AESが危殆化 するレベルの量子コンピュータは世に存在していない
• 代替アルゴリズムがないという「脆弱性」は指摘されている • 非公開アルゴリズムを使っている暗号化は信用してはいけない • アルゴリズムは公開されているので、安全性を担保するのは 「いかに鍵を管理するか」につきる • KMSは安全に鍵を管理するためのサービス • GCPにもCloud Key Management Serviceという同様の機能がある
AWS KMSの概要 • 自前の暗号化はもちろん、RDS, S3, EBSなどの透過的暗号化で も使える • マニアックなオプションとして、CloudHSMで鍵の持ち込みも 可能
• 東京では$1.81/h(今のレートで月額15万円弱) • 金融系の会社で使うことがあるらしい • 鍵のローテーション(交換)も可能 • セキュリティ上の要請がある場合に使う • 暗号論的安全な乱数を生成する機能もある
メリット • なんといっても暗号鍵の管理が楽 • 自分で暗号鍵を持つ場合 • どこに置けばいいのか • どのように管理・デプロイすればよいのか •
ハードコードしてリポジトリに入れてたりしないですよね・・・ • KMSならAPI経由で生成・取得可能 • IAMで権限管理できる • CloudTrailで利用ログも記録できる
間違えないで • KMSはデータを安全に暗号化するためのサービス • たとえば個人情報を保存したいとき • 秘密情報のデプロイに使うサービスではない • アクセストークン、DBパスワード、サーバ証明書秘密鍵など •
AWS Systems ManagerのParameter Store, AWS Secrets Managerを使います • これはこれで便利なサービス • APIキーのデプロイはEC2 Roleを使う
登場する鍵 • Master Key: 頂点となる鍵 • この鍵で直接暗号化できるが、 データ長と時間あたりの処理回 数などに制限がある •
マイナンバーなど短い文字列な らこれでいける • Data Key: 長いデータの暗号 化に使う • Master Keyで暗号化して保存 • これがenvelope encryption
アプリケーションでの鍵の管理 • Master Key暗号化はAPIに平文を送ると、暗号文が返ってくる • ローカルに鍵を置かないので、管理を考える必要はない • Envelope encryptionはAPIに平文の鍵と暗号化された鍵をリク エストする
• 「平文の鍵で暗号化」して、「暗号化された鍵を保存」する • 平文の鍵は/tmpに置いたりせず、オンメモリで処理を完了させる • ではAPIリクエストするためのキーは? • 流出すると鍵が入手できてしまうので、暗号化の意味がない • EC2 Instance Roleでインスタンスに権限を付与しましょう
データキーによる暗号化 • GenerateDataKeyでデータ キーを要求すると、平文の鍵 と暗号化された鍵が返る • 暗号化したいデータを「平文 の鍵」で暗号化し、暗号化さ れたデータとセットで「暗号 化された鍵」を保存する
• 暗号化は自分で行う • 平文鍵の処理はすべてオンメモ リで行う
データキーによる復号 • Decryptに暗号化された鍵を 送ると、平文の鍵が返る • 返ってきた鍵で暗号化された データを復号する • 復号も自分でやる •
平文の鍵はやはりオンメモリで 処理する必要がある
Encryption context? • KMS Encrypt APIのリクエスト構造は以下の通り { "EncryptionContext": { "string"
: "string" }, "GrantTokens": [ "string" ], "KeyId": "string", "Plaintext": blob } • Encryption Contextという引数を与えることができる • これは何だろう?
認証付き暗号 • 鍵が共通なので、攻撃者が何らかの方法で暗号文を入手した場合、 暗号を解読できてしまう • ターゲットの暗号文カラムを自分の行にコピーできた場合など • 秘匿性(Confidentiality)しか満たされない • 「混乱した使節」(confused
deputy) • Encryption contextつきの暗号文は、復号に同じcontextが必要 • これが「追加認証データ」(AAD; Additional Authenticated Data) • UIDなどを使うことが多い • 暗号時に認証するので「認証付き暗号」(AEAD; Authenticated Encryption with Associated Data) • 完全性(Integrity), 可用性(Availability)が満たされる • 可用性は「認可された人が」常に使えるという意味
まとめ • データを暗号化して保存するときはKMSを利用すべき • 暗号アルゴリズムは(今のところ)256bit AESが鉄板 • その上で、鍵の管理方法だけ注意すれば良い • ユーザーデータのように一意キーが使える場合は、認証付き暗
号を積極的に利用しよう
参考資料 • だいたいこのあたりを見ればわかります • AWS Key Management Service 開発者ガイド •
https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/overvie w.html • AWS Black Belt Techシリーズ AWS Key Management Service • https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt- tech-aws-key-management-service • AWS再入門 – Amazon KMS編 • https://dev.classmethod.jp/cloud/aws/cm-advent-calendar-2015-aws- relearning-key-management-service/