APKからAPIキーが読めてしまう- Lambdaを挟んだら安全になるのか

Transcript

1. APKからAPIキーが読めてしまう ― Lambdaを挟んだら安全になるのか 日本システム技術株式会社 野口 碧矢 2026/10/19 #ToBeAWSJrChampions2027
2. 自己紹介 ▪ 名前：野口 碧矢 ▪ 社会人歴：1年目 ▪ 業務内容：物流システムのWeb・モバイルアプリ開発 ▪ AWS学習歴：2ヵ月 ▪ GitHub：https://github.com/A0yyy36 ▪ Qiita：https://qiita.com/A0yyy36 ▪ ポートフォリオ：https://a0yyy36.github.io/my-garden/
3. 前提 ▪ 自主学習で本の登録・削除アプリを作成(Kotlin・XML) 今回の題材：このアプリのGoogle Books APIキーをどう守るか APIキー付きで直接通信
4. APKを開いたら、キーが見えた ▪ 自作アプリのAPKを逆コンパイラ(jadx)で開くと、APIキーが平文で読めた ※今回はAPIキーを”SampleAPIKey”というダミー値に変えてビルド
5. Lambdaを挟んでAPIキーを隠す APIキーはLambdaの環境変数へ移動 → アプリはGoogle Books APIを直接呼ばない
6. 新たな問題:API Gatewayキーがアプリに残る APIキーは隠せたが、API GatewayキーをAndroidアプリが保持している
7. 公開されているAPI Gatewayに対して上限を決める ▪ ▪ 使用量プラン (API Gateway)で、APIキーごとに使える量を制限 5 10 1,000 リクエスト / 秒 (レート) バースト 回 / 日 (クォータ) 日次クォータを小さくして確認 → 超過すると429 Limit Exceeded が返った (詳細はAppendix)
8. 制限は効いたか ▪ 15秒間、8並列でGET /booksを連打（実測の平均値【3回】） 範囲：83～85 84 200(成功) ⇒理論値(85件)とほぼ同等 ※実測の結果（1回分） 1,311 429(制限) 1,395 合計リクエスト
9. 【今後の展望】入口を守る: WAF + 認証 JWT = ログイン済みであることを証明する 期限付きの署名付きトークン
10. まとめ ▪ Lambdaを挟んだだけでは安全にはならない ▪ APIキーは隠せるが、入口(API Gateway)は公開のまま ▪ 使用量プランで被害を限定する ※同じキーを使う正規ユーザーも、枠を使い切ると使えなくなる 今後の展望 → WAFで怪しいアクセスをブロック → Cognito等で誰からのリクエストかの確認
11. Appendix
12. API Gatewayキーは隠せない ▪ APIキーを隠すことは出来たが、API Gatewayキーが出てしまっている ※今回はAPI Gatewayキーを”SampleAPIGatewayKey”というダミー値に変えてビルド
13. 日次クォータを超過した際の実行結果例 ▪ 実行環境: 50回/日 (クォータ) ▪ 超過後5リクエストで実行中止 50 5 55 200(成功) 429(Limit Exceeded) 総数 ※実測の一例
14. 何故理論値と一致しないのか ▪ AWS自身が「厳密な上限」としていない AWSのドキュメントでは、スロットリングは「ベストエフォート」で適用 されると説明されている。API Gatewayは複数のノードで分散処理されて いるため、トークンの管理が1つのバケットで完結せず、数件のズレが出る。 ▪ スロットリングはベストエフォートで適用される（AWSドキュメント）。 そのため、実測は理論値85件に対して83〜85件と、数件のずれが出た。分 散処理の影響が考えられる。 https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api -gateway-request-throttling.html
15. 理論値の算出方法 5 10 15 リクエスト / 秒 (レート) バースト 秒間 5(リクエスト/秒) × 15(秒) + 10(バースト) = 85件(理論値)
16. 本システムの問題点 ▪ 共有枠なので、一人が使い切ると全員に影響が出る → 使用量プランの枠は全員で共有しているため、誰かが使い切ると正規の ユーザーも429となる。 → 攻撃者と正規ユーザーが同じキーを使うため、区別できない。そのため WAFと認証が必要
17. ログイン部分の選択肢 1. ログイン画面を追加：Cognitoでサインイン機能を作る 2. Cognitoの未認証IDを利用する：ユーザーがログインしていなくても、設 定に応じて一時的なAWS認証情報を取得(個人の特定ではなく識別) 3. Play Integrity APIを利用する：正規のアプリ・端末からのリクエストかを 確認 ※ ログインなしで確認できるのは「誰か」ではなく「正規のアプリか」
18. REST APIを選んだ理由 ▪ 本システムはREST APIを採用している ▪ REST APIは使用量プランを適用できる ▪ REST APIはWAFを直接アタッチできるため、今後の入口防御に向いている ▪ HTTP APIの場合は、CloudFrontを経由してWAFを適用する必要がある
19. 書籍管理アプリのUI（管理画面）
20. 書籍管理アプリのUI（検索画面）