GO株式会社では、提供しているサービスが行っているメール配信機能の一部をクラウドメール配信サービスである「SendGrid」を利用して送付しています。
SendGridにはサブユーザという親アカウントに紐づく子アカウントのような形でアカウントを管理することができる機能があり、GOでもサービス・環境別にサブユーザを作成して運用しています。
この記事では弊社でのSendGridにおけるサブユーザの運用事例をご紹介できればと思います。
SREグループ・ヒロチカです。GOでは、サービスのクラウドインフラの設計から構築・運用までを担当しています。
GOの提供するサービスがメール配信を行う場合、自前でメールサーバを用意するのではなく、マネージドなメール配信ツールであるSendGridを利用して機能を実現しています。これは、運用面での権限管理やメンテナンスのコスト、実際にかかるサーバ費・通信コスト、などを考慮した上で同様サービスと比較し選定しています。
弊社がSendGridを使ってメールを送信する場面は、メルマガのような同一コンテンツの大規模一斉配信ではなく、各エンドユーザ様に対する領収書情報の送信や、ご契約いただいている企業様へのレポート配信など、各システムからのSendGrid APIを経由した個々へのメール送信がほとんどです。そのため、サービス運用時には、然るべきユーザに対して正しくメール送信がなされているかなどの確認を、実装したエンジニアだけでなく運営や企画のメンバーも行うことも多いのですが、この点においてSendGridには、充実した機能を含むマネージドなダッシュボードが存在し、直接サーバに入って送信ログを確認する(もしくはそれを自社で準備し提供する)ことなく、スマートに状況確認を行える点で非常に重宝しています。
しかしながら、SendGridが個人情報であるメールアドレスを扱う特性上、例えば、自分が従事していない別のサービスの送信ログなども見れてしまうといったことがあれば、セキュリティ上大変問題となってしまいます。担当するサービスや環境に合わせて、正しく権限が許可され管理されている状況を確実に作らなくてはなりません。
そんなケースにおいて、アカウントレベルで分けて管理できるサブユーザ機能は大変ニーズにあっており、弊社では運用上なくてはならないものとなっています。
GOでのサブユーザ管理の構成イメージになります。
親アカウントには、弊社が契約するSendGrid自体の管理者ならびにサブユーザ全体を監督する管理者のみをTeammates(※1)に所属させています。
それぞれのサブユーザのTeammatesに個人ユーザを所属させ、その個人ユーザがメール送信ログやダッシュボードの参照を行っています。また、所属させる個人ユーザには、必要最低限の権限のみを付与しています。
サブユーザの切り方は、メール送信を利用するサービス×環境の組み合わせで行い、各サブユーザに紐づくteammatesへの個人ユーザ招待は、大元の親アカウントの管理者が、各サービスの責任者承認の上で行なっています。
デフォルト状態のままだとサブユーザを作成できる数が少ないため、サブユーザ数が足りなくなった場合には、問い合わせから上限を引き上げていただいています。
※1)Teammates
SendGridには、親アカウントもしくは子アカウント(サブユーザ)の1つに対して1つ紐づくTeammatesという複数人でのユーザ管理のための機能が存在します。これは、親アカウントもしくは子アカウント(サブユーザ)の1つを複数人で管理したい場合に、アカウント自体のログインIDやパスワードを共有して管理するのではなく、Teammatesに所属させた個人ユーザが対象アカウントの管理をできるようにする機能です。このTeammatesに所属させた個人ユーザ対してもアカウント内部で操作できる権限の制限ができ、ログイン自体もアカウント別に独立しています(複数のサブユーザそれぞれで、個人ユーザのログイン情報が異なる)。
SendGridのサブユーザ機能は、それぞれのサービス従事者がお互いに独立した環境でダッシュボード・ログを確認することが可能で、そこが最大の利点だと考えます。サービス・環境別の状態のダッシュボード・送信ステータスがすぐに参照できることは、特にメール送信トラブルがあった場合の問い合わせ等へのレスポンスの速さにもつながっていると感じます。
また、システムからメール送信を行うために必要なAPI Keyをサブユーザごとに分けて作成できる点も、セキュリティリスクの低減につながると思います。
親アカウント並びにサブユーザ別にteammatesを設定することとなるため、複数のサブユーザにアクセスしたい個人ユーザは、それぞれのサブユーザに対し都度ログインをし直す必要があります。安全といえば安全ですが、ここはユーザ体験として不便に感じる人もいるかもしれません。
同様に、親アカウントに属する管理者が行うサブユーザのteammates管理においても、複数の環境・サービス単位での招待が必要となるため、多少煩雑に感じる部分があります。
加えて、弊社ではインフラ関連の構成管理を主にterraformでおこなっているのですが、SendGrid関連のproviderがあまり充実していないため、サブユーザやteammateのコード管理についてもまだ課題がある状態です。
SendGridとプランを決めて契約しているのはあくまで親アカウントなので、サブユーザからしてみれば、大元の契約に対する共用ホスティングをおこなっているような状態です。つまり、契約している最大送信メール通数などは親アカウントベースでの管理となります。これは、どこかのサブユーザが大量にメール配信したせいで契約した通数をオーバーしてしまい、一通あたりの送信メールのコストがかかるといったトラブルの可能性を含んでいます。SendGridの親アカウントの管理者は、各サブユーザが想定外の使われ方をしていないか十分注意しておく必要があります。メールの送信数については、全体への影響が起きないようサブユーザごとに通数制限の設定も可能となっています。対策の一つとして有効かもしれません。
送信元のIPアドレスやDNSの設定についても、親アカウントでの設定を継承した場合に、同じIPアドレス・ドメインの情報を共有することとなるため、他サブユーザの影響を受けてしまうことがあります。この通信部分についてより独立性を持たせたい場合には、IPアドレスを複数契約しサブユーザ別で割り当てるといったことを検討してもよいかもしれません。
今回は、弊社でのSendGridにおけるサブユーザ機能の運用方法をご紹介いたしました。
個人情報を伴う機能をサービスで運用していくにあたり、もし仮に自社でサーバを建てて安全な形のユーザ管理・運用を行う仕組みを1から作るといった場合、大変なことが容易に想像できます。
その点、SendGridを利用することで、SaaS側からより安全な形に倒した権限管理の機能を提供いただけていることは、本来行いたい弊社のサービス面の開発・改善に従事できる点でも有り難さを感じております。
この記事が、SendGridを利用または検討されている方の参考になりましたら、幸いです。
興味のある方は 採用ページ も見ていただけると嬉しいです。
Twitter @goinc_techtalk のフォローもよろしくお願いします!