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アカウント管理と踏み台サーバのあり方
Search
石川 将吾
April 03, 2020
3
760
仮想通貨取引所における AWSアカウント管理と踏み台サーバのあり方
JAWS DAYS 2020
石川 将吾
April 03, 2020
Tweet
Share
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
20
1.1k
Designing Experiences People Love
moore
138
23k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Writing Fast Ruby
sferik
627
61k
Testing 201, or: Great Expectations
jmmastey
38
7.1k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
The Language of Interfaces
destraynor
154
24k
Git: the NoSQL Database
bkeepers
PRO
427
64k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Transcript
ビットバンク株式会社 仮想通貨取引所における AWSアカウント管理と踏み台サーバのあり方 石川 将吾 JAWS DAYS 2020
© bitbank inc. 自己紹介 # 名前 石川 将吾 # 所属
ビットバンク株式会社 AWSエンジニア # Twitter koarakko99 2
© bitbank inc. 会社紹介 仮想通貨取引所(bitbank.cc)
3
© bitbank inc. 今回話すこと • AWSアカウント管理の取り組み • まとめ • 踏み台サーバの取り組み
• まとめ 4
AWSアカウント管理の取り組み 5
© bitbank inc. 請求 & 管理アカウント bitbankのAWSアカウント構成
6 本番 アカウント AWS Organization 開発 アカウント ステージング アカウント ログ管理 アカウント 統制 アカウント 踏み台
© bitbank inc. AWSアカウントを分けることのメリット AWS SSO(Single Sign-On)による権限割り当ての単純化 • アカウントごとにIAMユーザーを作らずに済む
コスト管理の単純化 • タグ管理とかで細かく設定しないで済む プロダクトが閉塞した場合にはアカウントごと削除できる • つまりリソースの消し忘れを無くせる 7
© bitbank inc. AWSアカウントの権限構成 AWS SSOを採用 • IAMユーザを使わない • 全アカウントはAWS
SSOからログイン 8
© bitbank inc. 承認ワークフローを用いた例 AWSアカウントにおいて作業や権限変更等に承認ワークフローを導入 AWSアカウント作成時 • 「アカウント名」、「理由」
AWSアカウント権限付与・削除 • 「対象アカウント」、「必要な権限」、「理由」 SecurityGroupやRoute53など影響があるサービス • 「対象リソース」、「理由」 9
© bitbank inc. アカウント作成時の承認ワークフローと連携した活用例 承認ワークフローと連携 • 承認後にアカウントを自動作成 さらにセキュリティサービスやエンタープライズサポートの有効を自動化 •
CloudTrail やGuardDuty 10
© bitbank inc. 定期的なアカウント権限の棚卸し 4半期ごとに権限を棚卸し • 不要な権限が割り当てられていないか • 不要な権限があれば削除を実施
11
© bitbank inc. AWSアカウント管理のまとめ 12 • AWSアカウントは環境・プロジェクトなどによってアカウントを分けている • セキュリティサービスはアカウント作成時に自動で有効化 •
権限変更(付与/削除)などの変更作業については承認ワークフローによる承認を必 須としている
踏み台サーバの取り組み 13
© bitbank inc. Session ManagerでなくEC2を踏み台として採用 • SSM Agentがインストールされていないサーバが多くあり、これからインストールす るのは現実的でなかった。
• 「誰が」接続したのか判別するのため設定が煩雑 ◦ Session Managerの場合、OSユーザを事前に用意が必要があり、運用担当者が代わるたびにOS ユーザの変更は現実的で無かった • ユーザ毎に接続先の権限管理が煩雑 ◦ AWS SSOでAWSアカウントを管理してるため、権限管理が煩雑になってしまう 14
© bitbank inc. 踏み台サーバの要件 要件 • セキュリティグループでの制限(インバウンド/アウトバウンド) • サーバログイン時の認証と通知 •
アプリケーションサーバへの接続できること • 各種ログ保管 ◦ 作業ログ ◦ サーバの稼動ログ 15
© bitbank inc. 本番作業用 ログ管理とモニタリング 秘密鍵管理 踏み台 ユーザ認証 踏み台サーバの全体構成図 16
EC2 EC2 DynamoDB Lambda Parameter Store ユーザ S3 CloudWatchLogs WorkSpaces Sumo Logic モニタリング 担当者 EC2(AD)
踏み台サーバの インバウンド・アウトバウンド 17
© bitbank inc. セキュリティグループの設定 セキュリティグループは最小限に制限 インバウンド • WorkSpacesからのみ(オフィスネットワークと分離するため)
アウトバウンド • SSH(22) アプリサーバ VPC Peeringを必須 • HTTPS(443) 18
踏み台サーバのログイン認証と通知 19
© bitbank inc. 踏み台ログイン認証 ログイン時の認証は次の通り ユーザー・パスワード認証 • 全てのユーザをAD連携 •
ログイン可能なユーザを特定ADグループに制限 MFA認証 • Google Authenticatorを利用した認証 20
© bitbank inc. 踏み台ログイン通知 ログイン通知 • サーバログイン時にSlack通知 • ユーザはスタンプでリアクションする
21 notify-login 1.ログイン 2.通知 3. リアクション
アプリケーションサーバへの接続方法の検討とその 仕組み 22
© bitbank inc. まずアプリケーションサーバにどのように繋ぐか 前提はLambdaやFargateを優先的に採用し、SSHできない環境にする ただし要件によっては、EC2レイヤーでのサーバが必要になってしまう アプリケーションサーバに接続する方法 • SSH秘密鍵で繋ぐ方法を採用した
23
© bitbank inc. 秘密鍵を管理するうえで考慮したこと 鍵の権限を管理する仕組み • 必要なユーザしか鍵を利用できないようにする 鍵が流出する可能性を減らす権限設計 •
不必要なところからの読み取りを排除する 恒常的に鍵を踏み台上に置かない仕組み • 利用するときのみ鍵ある状態にする 24
© bitbank inc. 鍵の権限を管理する仕組み Lambda • 鍵配信のエンドポイントとして利用 25 DynamoDB
• ユーザの鍵の権限管理するテーブル SSM(Parameter Store) • 秘密鍵を格納
© 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.鍵を配信
© bitbank inc. 鍵が流出する可能性を減らす権限構成(1) 27 まず鍵の中身をユーザが読めてしまう • sshする場合、chmod 400権限が必要 •
この時点でユーザ自身に読み取り権限を付与してしまう sshで秘密鍵を利用する限り、このレイヤーでの対策はできない
© 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 踏み台 アプリサーバ
© bitbank inc. 恒常的に鍵を踏み台上に置かない仕組み 29 ログイン時の鍵配信の仕組みに加えログアウトしたら鍵を自動削除 • 踏み台からユーザがログアウトしたら鍵を削除 踏み台 ログアウト
鍵を削除 UserCheck Daemon
ログ管理とモニタリング 30
© bitbank inc. 取得すべきログの要件 31 • 本番作業の証跡となるログ ◦ 事後モニタリングのため •
踏み台サーバとアプリサーバへの接続ログ ◦ 事後モニタリングのため • サーバのメッセージログ ◦ トラブルシューティング
© bitbank inc. 取得しているログの例 32 本番作業の事後モニタリングのため • ユーザの打鍵したコマンドとその実行結果 • SSH接続と切断ログ
サーバ障害時のトラブルシューティングのため • サーバのメッセージログ
© bitbank inc. 打鍵ログはS3、CloudWatchで保管し、SumoLogicに連携している ログの保管期間は3年(監査などに対応するため) ログの連携方法と保管期間 33 打鍵ログ SSH切断/切断
ログ メッセージログ 打鍵ログ Sumo Logic CloudWatchLogs S3 踏み台 モニタリング 担当者 etc ・ ・ ・
その他の OSレベルでの取り組み 34
© bitbank inc. 不要なコマンドの実行権限を排除 35 SELinuxのLevelを活用したユーザからコマンド実行権限を剥奪
[
[email protected]
~]$ ls -Z /usr/bin/make system_u:object_r:bin_t:s15 /usr/bin/make
© bitbank inc. ユーザ毎にホームディレクトリを分離 36 Chrootでユーザ毎のルートディレクトリを変更 • ユーザが他ユーザのホームディレクトリを覗けなくする
chroot / /home /etc /user1 /home /user1 /bin /etc chroot /user2 /home /user2 /bin /etc /bin
運用時のトラブル 37
© bitbank inc. Google AuthenticatorによるMFAがエラーになる 38 原因 • セキュリティグループでアウトバウンド制限していたため、NTPに接続を拒否してい た
• このため時間同期できずサーバ内の時間がズレてしまった 対応 • Amazon Time Sync Serviceを使って時刻同期するようにした • SGのアウトバウンドを開ける必要がないのがメリット
© bitbank inc. 踏み台のまとめ 39 • 踏み台についてはEC2を採用 • 各アプリケーションサーバへの接続方法はSSH秘密鍵を利用 •
鍵の権限管理はLambda/Dynamo/SSMとカーネルレベルのSELinuxを利用 • 監査等に対応できるログを取得し、モニタリングを実施
© bitbank inc. エンジニア募集中です 40 • AWSエンジニア • SREエンジニア •
フロントエンドエンジニア • バックエンドエンジニア • データ基盤エンジニア
41 ビットコインの技術で 世界中にあらゆる価値を流通させる