Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

石川 将吾
April 03, 2020
760

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

JAWS DAYS 2020

石川 将吾

April 03, 2020
Tweet

Transcript

  1. © bitbank inc. 自己紹介 # 名前
 石川 将吾
 
 # 所属


    ビットバンク株式会社 AWSエンジニア
 
 # Twitter
 koarakko99
 
 
 2
  2. © bitbank inc. 
 
 
 請求 & 管理アカウント
 bitbankのAWSアカウント構成

    6 
 
 本番
 アカウント
 AWS Organization
 
 開発
 アカウント
 
 ステージング
 アカウント
 
 ログ管理
 アカウント
 
    統制
 アカウント
 踏み台

  3. © bitbank inc. AWSアカウントを分けることのメリット AWS SSO(Single Sign-On)による権限割り当ての単純化
 • アカウントごとにIAMユーザーを作らずに済む
 


    コスト管理の単純化
 • タグ管理とかで細かく設定しないで済む
 
 プロダクトが閉塞した場合にはアカウントごと削除できる
 • つまりリソースの消し忘れを無くせる
 
 7
  4. © bitbank inc. 承認ワークフローを用いた例 AWSアカウントにおいて作業や権限変更等に承認ワークフローを導入
 
 AWSアカウント作成時
 • 「アカウント名」、「理由」
 


    AWSアカウント権限付与・削除
 • 「対象アカウント」、「必要な権限」、「理由」
 
 SecurityGroupやRoute53など影響があるサービス
 • 「対象リソース」、「理由」
 9
  5. © bitbank inc. Session ManagerでなくEC2を踏み台として採用 • SSM Agentがインストールされていないサーバが多くあり、これからインストールす るのは現実的でなかった。
 


    • 「誰が」接続したのか判別するのため設定が煩雑
 ◦ Session Managerの場合、OSユーザを事前に用意が必要があり、運用担当者が代わるたびにOS ユーザの変更は現実的で無かった 
 
 • ユーザ毎に接続先の権限管理が煩雑
 ◦ AWS SSOでAWSアカウントを管理してるため、権限管理が煩雑になってしまう 
 
 
 14
  6. © bitbank inc. 踏み台サーバの要件 要件
 • セキュリティグループでの制限(インバウンド/アウトバウンド)
 • サーバログイン時の認証と通知
 •

    アプリケーションサーバへの接続できること
 • 各種ログ保管
 ◦ 作業ログ
 ◦ サーバの稼動ログ
 
 
 
 15
  7. © bitbank inc. 本番作業用
 ログ管理とモニタリング
 秘密鍵管理
 踏み台
 ユーザ認証
 踏み台サーバの全体構成図 16

    EC2 EC2 DynamoDB Lambda Parameter Store ユーザ S3 CloudWatchLogs WorkSpaces Sumo Logic モニタリング
 担当者
 EC2(AD)
  8. © bitbank inc. 踏み台ログイン認証 ログイン時の認証は次の通り
 
 ユーザー・パスワード認証
 • 全てのユーザをAD連携
 •

    ログイン可能なユーザを特定ADグループに制限
 
 MFA認証
 • Google Authenticatorを利用した認証
 
 
 20
  9. © bitbank inc. 秘密鍵を管理するうえで考慮したこと 鍵の権限を管理する仕組み
 • 必要なユーザしか鍵を利用できないようにする
 
 鍵が流出する可能性を減らす権限設計
 •

    不必要なところからの読み取りを排除する
 
 恒常的に鍵を踏み台上に置かない仕組み
 • 利用するときのみ鍵ある状態にする
 
  
 24
  10. © bitbank inc. 鍵の権限を管理する仕組み Lambda
 • 鍵配信のエンドポイントとして利用
 
 25 DynamoDB


    • ユーザの鍵の権限管理するテーブル
 
 SSM(Parameter Store)
 • 秘密鍵を格納

  11. © 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.鍵を配信
  12. © bitbank inc. 鍵が流出する可能性を減らす権限構成(1) 27 まず鍵の中身をユーザが読めてしまう
 • sshする場合、chmod 400権限が必要
 •

    この時点でユーザ自身に読み取り権限を付与してしまう
 
 sshで秘密鍵を利用する限り、このレイヤーでの対策はできない

  13. © 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 踏み台
 アプリサーバ

  14. © bitbank inc. 取得すべきログの要件 31 • 本番作業の証跡となるログ
 ◦ 事後モニタリングのため
 •

    踏み台サーバとアプリサーバへの接続ログ
 ◦ 事後モニタリングのため
 • サーバのメッセージログ
 ◦ トラブルシューティング
 

  15. © bitbank inc. Google AuthenticatorによるMFAがエラーになる 38 原因
 • セキュリティグループでアウトバウンド制限していたため、NTPに接続を拒否してい た


    • このため時間同期できずサーバ内の時間がズレてしまった
 
 対応
 • Amazon Time Sync Serviceを使って時刻同期するようにした
 • SGのアウトバウンドを開ける必要がないのがメリット
 
 

  16. © bitbank inc. 踏み台のまとめ 39 • 踏み台についてはEC2を採用
 • 各アプリケーションサーバへの接続方法はSSH秘密鍵を利用
 •

    鍵の権限管理はLambda/Dynamo/SSMとカーネルレベルのSELinuxを利用
 • 監査等に対応できるログを取得し、モニタリングを実施
 
 

  17. © bitbank inc. エンジニア募集中です 40 • AWSエンジニア
 • SREエンジニア
 •

    フロントエンドエンジニア
 • バックエンドエンジニア
 • データ基盤エンジニア