私はDoiTで、クラウド活用を始めたばかりのスタートアップを日々支援しています。
そこで目にするのは、いつも同じような失敗ばかりです。
修正に高いコストや手間がかかる前に回避していただけるよう、代表的なものをいくつか紹介します。
1\. 創業者の個人メールアドレスでAWSアカウントを開設している
最初のAWSアカウントが、創業者個人のGmailアドレスで作成されているケースは非常によくあります。
この場合、アカウントは法的にも運用上も「個人」に紐づいており、会社の資産にはなっていません。
創業者の退職、対立、最悪の場合は本人に何かあったとき、所有権が深刻なビジネスリスクになります。
加えて、個人メールは法人のメールボックスに比べてセキュリティが弱いのが一般的です。MFAの強制適用や集中監査の仕組みがなく、ID統制も不十分で、認証取得の監査においても大きな障害となります。
創業者のメールが侵害されれば、会社のAWS環境ごと乗っ取られかねません。
これは単一障害点を生む構造でもあります。
ベストプラクティス:
共有のグループメールボックスを用意しましょう。例: [email protected]
少なくとも2名のメンバーを登録し(誰かしら病気・休暇・出張で不在になります)、プラスアドレッシングでAWSアカウントごとの環境を分けましょう。
2\. Management Accountでリソースを作成している
スタートアップは多くの場合、本番、開発、デモ、開発者の検証用まで、すべてを単一のAWSアカウントで運用するところから始まります。
会社の成長に伴って環境の分離が必要になったとき、最も手軽に見える方法が、この単一アカウントをそのままAWS OrganizationsのManagement Accountにし、組織配下に新しいメンバーアカウントを作っていくやり方です。
しかし問題があります。Management Accountは、組織全体のガバナンスポリシーを適用できない唯一のアカウントなのです。
AWS Organizations Service Control Policies ドキュメント
たとえば、次のようなポリシーを適用したくなるはずです。
- EC2のEBSボリュームはすべて暗号化必須
- 許可されていないリージョンでのリソース作成を禁止
- 高額なインスタンスタイプ(GPU)を制限
- IAMユーザーは禁止し、ロールのみ許可
これらはどれもManagement Accountには適用されません。しかも、本ケースではそのManagement Accountが本番アカウントを兼ねている状態です。
さらに厄介なことに、AWSはManagement Accountをメンバーアカウントへ変換することを認めていません。
本番アカウントがそのままManagement Accountになっている場合、唯一の打ち手は組織全体の作り直しです。組織の再構築、ポリシーの再作成、権限の再設定、そして全社員を新しいSingle Sign On(SSO)エンドポイントへ再オンボーディングする必要があります。
現在すべてが単一のAWSアカウントで動いていて、これから環境を分けたい段階であれば、新しい独立したAWSアカウントを作成し、それをAWS OrganizationsのManagement Accountに設定したうえで、既存の本番アカウントをメンバーアカウントとして新しい組織に招待しましょう。
3\. コンプライアンス対応の先送り
エンタープライズ顧客への販売を視野に入れているなら、いずれ必ずコンプライアンス対応を求められます。
- B2B SaaS向けのSOC 2 / ISO 27001
- ヘルスケア向けのHIPAA
- フィンテック・決済向けのPCI DSS
すでに動いているプロダクトと組織を、後からコンプライアンス要件に合わせ込むのは極めて困難です。
影響はクラウドアーキテクチャにとどまらず、開発ワークフロー、アクセス制御、さらには雇用契約(知的財産の帰属、機密保持、デバイス管理など)にまで及びます。
クラウドインフラの修正は大変ですが、何とかやり遂げられます。一方で、契約や組織プロセスを後から変えるのは比べものにならないほど難しい。だからこそ、プロダクトの最初の一行を書く段階からコンプライアンスのアドバイザリーパートナーと組んでおけば、その後の道のりは格段にスムーズになります。
4\. 卵をひとつのカゴに盛らない
AWSでは、ドメインの登録・更新・DNS管理をRoute 53にまとめられます。便利ですが、同時に危険でもあります。
請求トラブル、セキュリティインシデント、IAMキーの漏洩などでAWSアカウントが停止されると、ドメインまで巻き添えになる恐れがあるからです。
メールが使えなくなれば、AWSサポートと連絡を取って問題を解決することすら極めて困難になります。
Reddit.com r/awsの投稿より
ベストプラクティス:
会社の主要ドメインは、メインの本番AWSアカウントの外で管理しましょう。GoDaddyやNameCheapといった別のレジストラ、あるいは専用のAWSアカウントに分離しておくのが理想です。万が一、本番アカウントからロックアウトされても、別のプロバイダやアカウント側でDNSレコードを維持できます。
5\. 有効期限カレンダーを整備し、重要な更新日を見逃さない
初年度であっても、スタートアップにはあっという間に次のようなものが積み重なっていきます。
- 契約
- APIキー
- クレジットカード
これらに共通するのは、いずれも有効期限がある点です。
典型的に起きてしまう困った事態は次のようなものです。
- 支払い未済によるAWSアカウントの停止
- APIキーの失効による突然のサービス障害
- 更新日の見落としや直前対応による、駆け込みの契約更新交渉
自動リマインダー付きの共有カレンダー(例: 「クレジットカード3344は30日後に期限切れ」「MAPプロバイダ契約の更新まで残り45日」)を活用すれば、こうした事態を未然に防げます。
おわりに
対処すべき課題は山ほどあります。強くお勧めしたいのは、自身も創業経験があり、複数のスタートアップを率いてきたメンターを見つけることです。経験に裏打ちされたアドバイスは、本当に値千金です。
初日から正しい形でクラウドを構築したいなら、DoiTのテクノロジーと専門知識、そしてスタートアップからグローバル企業まで支援してきた長年の経験を活用してください。ここで挙げた失敗はもちろん、その他多くの落とし穴の回避をお手伝いします。
クラウドをリスク要因ではなく、成長エンジンに変えていきましょう。