仮想通貨取引所における AWSアカウント管理と踏み台サーバのあり方

JAWS DAYS 2020

Transcript

1. ビットバンク株式会社 仮想通貨取引所における AWSアカウント管理と踏み台サーバのあり方 石川　将吾
 JAWS DAYS 2020
2. © bitbank inc. 自己紹介 # 名前
 石川　将吾
 
 # 所属
 ビットバンク株式会社 AWSエンジニア
 
 # Twitter
 koarakko99
 
 
 2
3. © bitbank inc. 会社紹介 仮想通貨取引所(bitbank.cc)
 
 
 
 
 
 3
4. © bitbank inc. 今回話すこと • AWSアカウント管理の取り組み
 • まとめ
 • 踏み台サーバの取り組み
 • まとめ
 4
5. AWSアカウント管理の取り組み 5
6. © bitbank inc. 
 
 
 請求 & 管理アカウント
 bitbankのAWSアカウント構成 6 
 
 本番
 アカウント
 AWS Organization
 
 開発
 アカウント
 
 ステージング
 アカウント
 
 ログ管理
 アカウント
 
 　 　統制
 アカウント
 踏み台

7. © bitbank inc. AWSアカウントを分けることのメリット AWS SSO(Single Sign-On)による権限割り当ての単純化
 • アカウントごとにIAMユーザーを作らずに済む
 
 コスト管理の単純化
 • タグ管理とかで細かく設定しないで済む
 
 プロダクトが閉塞した場合にはアカウントごと削除できる
 • つまりリソースの消し忘れを無くせる
 
 7
8. © bitbank inc. AWSアカウントの権限構成 AWS SSOを採用
 • IAMユーザを使わない
 • 全アカウントはAWS SSOからログイン
 8
9. © bitbank inc. 承認ワークフローを用いた例 AWSアカウントにおいて作業や権限変更等に承認ワークフローを導入
 
 AWSアカウント作成時
 • 「アカウント名」、「理由」
 
 AWSアカウント権限付与・削除
 • 「対象アカウント」、「必要な権限」、「理由」
 
 SecurityGroupやRoute53など影響があるサービス
 • 「対象リソース」、「理由」
 9
10. © bitbank inc. アカウント作成時の承認ワークフローと連携した活用例 承認ワークフローと連携
 • 承認後にアカウントを自動作成
 
 さらにセキュリティサービスやエンタープライズサポートの有効を自動化
 • CloudTrail やGuardDuty
 
 10
11. © bitbank inc. 定期的なアカウント権限の棚卸し ４半期ごとに権限を棚卸し
 • 不要な権限が割り当てられていないか
 • 不要な権限があれば削除を実施
 
 
 11
12. © bitbank inc. AWSアカウント管理のまとめ 12 • AWSアカウントは環境・プロジェクトなどによってアカウントを分けている
 • セキュリティサービスはアカウント作成時に自動で有効化
 • 権限変更(付与/削除）などの変更作業については承認ワークフローによる承認を必 須としている

13. 踏み台サーバの取り組み 13
14. © bitbank inc. Session ManagerでなくEC2を踏み台として採用 • SSM Agentがインストールされていないサーバが多くあり、これからインストールす るのは現実的でなかった。
 
 • 「誰が」接続したのか判別するのため設定が煩雑
 ◦ Session Managerの場合、OSユーザを事前に用意が必要があり、運用担当者が代わるたびにOS ユーザの変更は現実的で無かった 
 
 • ユーザ毎に接続先の権限管理が煩雑
 ◦ AWS SSOでAWSアカウントを管理してるため、権限管理が煩雑になってしまう 
 
 
 14
15. © bitbank inc. 踏み台サーバの要件 要件
 • セキュリティグループでの制限(インバウンド/アウトバウンド)
 • サーバログイン時の認証と通知
 • アプリケーションサーバへの接続できること
 • 各種ログ保管
 ◦ 作業ログ
 ◦ サーバの稼動ログ
 
 
 
 15
16. © bitbank inc. 本番作業用
 ログ管理とモニタリング
 秘密鍵管理
 踏み台
 ユーザ認証
 踏み台サーバの全体構成図 16 EC2 EC2 DynamoDB Lambda Parameter Store ユーザ S3 CloudWatchLogs WorkSpaces Sumo Logic モニタリング
 担当者
 EC2(AD)
17. 踏み台サーバの インバウンド・アウトバウンド 17
18. © bitbank inc. セキュリティグループの設定 セキュリティグループは最小限に制限
 
 インバウンド
 • WorkSpacesからのみ（オフィスネットワークと分離するため）
 
 アウトバウンド
 • SSH(22) アプリサーバ VPC Peeringを必須
 • HTTPS(443) 
 
 
 18
19. 踏み台サーバのログイン認証と通知 19
20. © bitbank inc. 踏み台ログイン認証 ログイン時の認証は次の通り
 
 ユーザー・パスワード認証
 • 全てのユーザをAD連携
 • ログイン可能なユーザを特定ADグループに制限
 
 MFA認証
 • Google Authenticatorを利用した認証
 
 
 20
21. © bitbank inc. 踏み台ログイン通知 ログイン通知
 • サーバログイン時にSlack通知
 • ユーザはスタンプでリアクションする
 
 
 21 notify-login 1.ログイン
 2.通知
 3. リアクション

22. アプリケーションサーバへの接続方法の検討とその 仕組み 22
23. © bitbank inc. まずアプリケーションサーバにどのように繋ぐか 前提はLambdaやFargateを優先的に採用し、SSHできない環境にする
 ただし要件によっては、EC2レイヤーでのサーバが必要になってしまう
 
 アプリケーションサーバに接続する方法
 • SSH秘密鍵で繋ぐ方法を採用した
 
 
 
 
 　
 23
24. © bitbank inc. 秘密鍵を管理するうえで考慮したこと 鍵の権限を管理する仕組み
 • 必要なユーザしか鍵を利用できないようにする
 
 鍵が流出する可能性を減らす権限設計
 • 不必要なところからの読み取りを排除する
 
 恒常的に鍵を踏み台上に置かない仕組み
 • 利用するときのみ鍵ある状態にする
 
 　
 24
25. © bitbank inc. 鍵の権限を管理する仕組み Lambda
 • 鍵配信のエンドポイントとして利用
 
 25 DynamoDB
 • ユーザの鍵の権限管理するテーブル
 
 SSM(Parameter Store)
 • 秘密鍵を格納

26. © bitbank inc. 秘密鍵の管理と配信の仕組み(流れ) 1. Lambdaを実行
 
 26 DynamoDB 1.実行 Parameter Store EC2 踏み台 2.ユーザの権限を 確認 3.鍵を取得 Lambda 2. DynamoDBでユーザの権限を確認
 3. SSMから鍵を取得
 user@ip-x-x-x-x .ssh]$ ls dev-test.pem dev-test-2.pem 4. 踏み台に秘密鍵を配信
 4.鍵を配信
27. © bitbank inc. 鍵が流出する可能性を減らす権限構成(1) 27 まず鍵の中身をユーザが読めてしまう
 • sshする場合、chmod 400権限が必要
 • この時点でユーザ自身に読み取り権限を付与してしまう
 
 sshで秘密鍵を利用する限り、このレイヤーでの対策はできない

28. © bitbank inc. 鍵が流出する可能性を減らす権限構成(2) 28 そこでSELinuxによるカーネルレベルでのアクセス制御
 • 秘密鍵の読み取り権限をユーザなどから剥奪した
 • ユーザがcat, echo, cpなどで鍵を読み取りできない
 • アプリサーバへSSHはUnix権限は chmod 400 であるため可能
 ssh App user@ip-x-x-x-x tmp]$ cat ~/.ssh/test.pem cat: /home/user/.ssh/test.pem: Permission denied cat 踏み台
 アプリサーバ

29. © bitbank inc. 恒常的に鍵を踏み台上に置かない仕組み 29 ログイン時の鍵配信の仕組みに加えログアウトしたら鍵を自動削除
 • 踏み台からユーザがログアウトしたら鍵を削除
 踏み台
 ログアウト
 鍵を削除
 UserCheck Daemon
30. ログ管理とモニタリング 30
31. © bitbank inc. 取得すべきログの要件 31 • 本番作業の証跡となるログ
 ◦ 事後モニタリングのため
 • 踏み台サーバとアプリサーバへの接続ログ
 ◦ 事後モニタリングのため
 • サーバのメッセージログ
 ◦ トラブルシューティング
 

32. © bitbank inc. 取得しているログの例 32 本番作業の事後モニタリングのため
 • ユーザの打鍵したコマンドとその実行結果
 • SSH接続と切断ログ
 
 サーバ障害時のトラブルシューティングのため
 • サーバのメッセージログ
 
 
 

33. © bitbank inc. 打鍵ログはS3、CloudWatchで保管し、SumoLogicに連携している
 ログの保管期間は３年（監査などに対応するため）
 
 ログの連携方法と保管期間 33 打鍵ログ SSH切断/切断 ログ メッセージログ 打鍵ログ Sumo Logic CloudWatchLogs S3 踏み台
 モニタリング
 担当者
 etc ・
 ・
 ・

34. その他の OSレベルでの取り組み 34
35. © bitbank inc. 不要なコマンドの実行権限を排除 35 SELinuxのLevelを活用したユーザからコマンド実行権限を剥奪
 
 
 
 
 
 
 
 [ec2-user@ip-x.x.x.x ~]$ ls -Z /usr/bin/make
 system_u:object_r:bin_t:s15 /usr/bin/make
36. © bitbank inc. ユーザ毎にホームディレクトリを分離 36 Chrootでユーザ毎のルートディレクトリを変更
 • ユーザが他ユーザのホームディレクトリを覗けなくする
 
 
 chroot
 / /home /etc /user1 /home /user1 /bin /etc 
 
 chroot
 /user2 /home /user2 /bin /etc /bin
37. 運用時のトラブル 37
38. © bitbank inc. Google AuthenticatorによるMFAがエラーになる 38 原因
 • セキュリティグループでアウトバウンド制限していたため、NTPに接続を拒否してい た
 • このため時間同期できずサーバ内の時間がズレてしまった
 
 対応
 • Amazon Time Sync Serviceを使って時刻同期するようにした
 • SGのアウトバウンドを開ける必要がないのがメリット
 
 

39. © bitbank inc. 踏み台のまとめ 39 • 踏み台についてはEC2を採用
 • 各アプリケーションサーバへの接続方法はSSH秘密鍵を利用
 • 鍵の権限管理はLambda/Dynamo/SSMとカーネルレベルのSELinuxを利用
 • 監査等に対応できるログを取得し、モニタリングを実施
 
 

40. © bitbank inc. エンジニア募集中です 40 • AWSエンジニア
 • SREエンジニア
 • フロントエンドエンジニア
 • バックエンドエンジニア
 • データ基盤エンジニア 
 
 

41. 41 ビットコインの技術で 世界中にあらゆる価値を流通させる