2023年5月1日を持ちまして、株式会社KDDIウェブコミュニケーションズのTwilioリセール事業が終了したため、本記事に記載されている内容は正確ではないことを予めご了承ください。
はじめに
みなさん、こんにちは。
KDDIウェブコミュニケーションズの Twilio事業部エバンジェリストの高橋です。
久しぶりの「Twilio で開発を始める前に知っておくこと」ですが、今回は最近色々とクラウドサービスのセキュリティ対策ってどうなん?っていう疑問について、Twilio の Programmable Voice を中心に書いてみます。
これから Twilio を使ってシステム構築する方はもちろん、すでに運用中のシステムをお持ちの方も、ぜひ一度読んでみてください。
Programmable Voice に関連するセキュリティ関連項目
Twilio を使って電話をかけたり、受けたりする機能が Programmable Voice というサービスです。
この機能に関連するセキュリティ項目というと、概ね次の2つになるかと思います。
- 通話ログに関するもの
- どのようなデータが保存されているのか
- どこに保存されているのか
- いつまで保存されているのか
- ログは誰が見られるのか
- ログを消すことはできるのか
- 録音データに関するもの
- どこに保存されているのか
- データは暗号化されているのか
- 誰が見られるのか
- 消すことはできるのか
- 操作(聞いた、ダウンロードした、消したなど)したログは取れるのか
どうです?気になりますよね。
ということで、この記事では通話ログにフォーカスをして解説をします。
録音データのセキュリティにつきましては、Twilioで開発を始める前にしておくこと(電話のセキュリティ 後編)にて解説をしていきます。
通話ログに関するセキュリティ
保存される場所
残念ながら、ログの保存場所については公開していません。
しかし、Twilio のシステムは AWS の8つのリージョン上の複数の Availability Zone の分散して管理をしているとの記述がこちらのドキュメント内に記録されています。
もしあなたの企業が、ログも日本限定で保存されていなくてはいけないというセキュリティポリシーをお持ちの場合は、Twilio ではポリシーを満たすことはできません。今までの経験上、このようなポリシーをお持ちの企業様は、保存されている国の法律によって、その国の誰かがデータを見られる可能性を指摘していますが、できればこの後の項目もぜひご覧いただき、保管場所の特定がどこまで必要かをご検討いただけると嬉しいです。
保存されているログ
まずは、Programmable Voice で記録されるコールログの項目を見ていきましょう。
その前に、そもそもコールログというものについても簡単に紹介します。
例えば、Aさんが Twilio を経由して Bさんに電話をかけたとしましょう(多くの場合、直接かけたほうが早いですが、この場合中間の050番号がBさんに通知されるので、Aさんの番号がBさんにはわからないというのがミソです)。
この例では、コールログは2つできることに注意してください。すなわち、Aさんが Twilio にかけたときのコールログと、Twilio からBさんにかけたコールログです。
このように、Twilio 内部ではコールごとにログが生成されるということがわかりました。
では早速ログの内容をみていきましょう。
項目名 | 説明 | PII |
---|---|---|
sid | 一意なID | - |
dateCreated | ログの生成日時 | - |
dateUpdated | ログの更新日時 | - |
parentCallSid | 親コールのID | - |
accountSid | アカウントSID | - |
to | 宛先番号 | 120days |
toFormatted | toを整形したもの | 120days |
from | 発信元番号 | 120days |
fromFormatted | fromを整形したもの | 120days |
phoneNumberSid | 発信もしくは着信に使われたTwilio番号のID | - |
status | コールの状態 | - |
startTime | コール開始日時 | - |
endTime | コール終了日時 | - |
duration | 通話時間 | - |
price | 通話料金 | - |
priceUnit | 通貨(日本はJPY) | - |
direction | 通話方向(着信か発信) | - |
answeredBy | 人間が受けたか機械が受けたか | - |
annotation | 注釈(詳細不明) | - |
apiVersion | Twilio APIのバージョン | - |
forwardedFrom | 転送元番号(日本は非対応) | - |
groupSid | 非使用 | - |
callerName | LOOKUPを利用した場合の発信者名 | 120days |
queueTime | キューに入っていた時間 | - |
trunkSid | SIP Trunkを使った場合のトランクID | - |
uri | 利用したAPIリソース(https://api.twilio.com/〜 ) |
- |
subresourceUris | 関連するAPIリソース | - |
かなりいろいろな項目が記録されているのがわかります。
この中で、セキュリティ上特に重要なのが、発信者番号(to, toFormatted)や、宛先の電話番号(from, fromFormatted)ではないかと思います。
そして、気になる項目にはそれぞれ PII として120days
と書いてあります。PII については、この後の保存期間のところで解説をします。
リクエストインスペクターについて
Twilio でシステム開発をしていると、どうしてもデバッグをする必要がでてきます。
すでにご紹介したコールログは、コールの最終的な状態を確認することができるのですが、途中で発生した各種APIリクエストを時系列で追いながら調べるのには向いていません。
そこで重宝するのが、リクエストインスペクターと呼ばれるツールです。
リクエストインスペクターを利用すると、たとえば以下のような形でコールを確認することができます。
上記画像の水色のマスクした部分には重要な情報が書かれています。
このように、デバッグで便利な機能も、セキュリティ上はリスクとなります。
このリクエストインスペクターは、コールが終了してから90日間は Twilio 上で確認が可能です。また、設定画面から、リクエストインスペクター機能自体を無効( DISABLED )にすることもできるので、本番環境で運用する場合などは無効に設定しておくと良いでしょう(デバッグが必要なときだけ有効にできます)。
IVR で収集したキー情報等について
Twilio では、Gather 動詞を使うことで、ユーザから対話形式で数字キーを取得することができます。たとえば、この機能を使ってクレジットカード番号を取得するようなケースでは、カード情報を扱うための PCI コンプライアンス に準拠する必要があります。
PCI コンプライアンスとは
主要なクレジットカード会社による、カード情報を安全に取り扱うための業界標準で、PCI/DSS(Payment Card Industry / Data Security Standard)と呼ばれます。
カード情報を扱う場合は、この PCI/DSS に準拠した非常に強固なシステムを利用する必要があります。
Twilioは、この PCI/DSS に準拠したシステムになっているので、例えばカード情報に該当してしまうような数字キーの履歴を外部からは参照できません。
ただし、この PCI/DSS に準拠したモードを利用するためには、設定画面で PCI モードを有効にする必要があります。
このモードの初期値は、無効
です。さらに、一度有効
に設定すると、もとに戻すことはできません。また、このモードが有効になっている場合は、先程のリクエストインスペクターでも押されたキーの情報は見ることができなくなります。
ここで誤解をしてはいけないことは、PCI モードを有効にしたので、皆さんの開発したシステムが PCI/DSS 準拠になったということではないということです。
たとえば、カード情報が Twilio 上で秘匿されたとしても、それを受け取った皆様側のシステムが PCI/DSS に準拠していなければいけないのです。
言い換えれば、Twilio における PCI/DSS 準拠というのは、あくまで Twilio をいうシステムを使って、電話口からカード情報を取得したとしても、その通信経路上は、PCI/DSS に準拠していますよというものなのです。
ここまで聞くと、皆さん側で PCI/DSS 準拠のシステムが作れないのであれば、そもそもこのモードはあまり意味がないと思われるかもしれません。
実は、Twilio には、PCI/DSS に準拠した決済専用のサービスがあるのです。それが、Twilio Pay です。正確には、Twilio Pay は決済事業者とのコネクタという位置づけで、たとえば Stripe 社の決済システムと Twilio を直接つないで Stripe 上で決済してしまおうという使い方です。Stripe 社は当然ですが、PCI/DSS に準拠しているため、皆さんのシステムを使わずに、それぞれ PCI/DSS に準拠した Twilio と Stripe で安全に決済を実現することができます。
Twilio Payにご興味を持った方は、実際に構築した事例記事などがございますので、ご参考まで。
StripeとTwilio Payで電話決済
Twilio Pay を使って電話決済を体験する(初級編)
閲覧権限
さて、少し話が横道にそれてしまいましたので、元に戻しましょう。
次に説明するのが、ログの閲覧権限です。
通常、コールログは管理コンソール上から確認するか、API を使って取得するかのいずれかで取得することができます。API を使う場合には、アクセスするための認証情報( AccountSid や AuthToken 、もしくは API Key と API Secret )が必要で、それぞれを正しく運用することでセキュリティを保ちます。
一方、管理コンソールからログを閲覧するという方法の場合、管理コンソールにログインしたユーザの権限が重要です。
ユーザには、いくつかのロールが用意されており、ロールはプロジェクトに招待する際に割り当てをすることができます。
ロールとかプロジェクトについては、以下の記事がわかりやすいので、よくわからないという方はぜひご覧ください。
Twilioで開発を始める前に知っておくこと(ユーザー管理編)
ここまで書いておいて今更なのですが、実はすべてのユーザロールでログの閲覧は可能です。
そう、つまりユーザの権限でログの閲覧を制限することはできないということになります。
これはすなわち、管理コンソールにログインできるユーザの認証を強固にする必要があることを意味します。すでに皆さんは設定を強制されているかと思いますが、現在 Twilio コンソールにログインするためには、二要素認証が必須となっています。
これ以外にも、たとえば退職した従業員のアカウントをちゃんと削除するとか、運用面での対策をしっかりと行うようにしてください。
ちなみに、Twilio のプロジェクトにアクセス可能なユーザのリストは、管理コンソール > 設定 > ユーザー管理で確認することができます。
ログの削除とログの保存期間
では最後に、ログの削除とログの保存期間について解説します。
まず、ログについてはユーザが明示的に削除するか、そのプロジェクトを削除するまでは残り続けます。自動的に消えることはありません。
そして、明示的な削除を行った場合、もしくはプロジェクトが削除された場合においても、ログの項目によっては一定期間 Twilio 上には保存されます。これは何のためかを理解するためには、まずはじめに PII について理解が必要です。
PII(Personally Identifiable Information)とは
これは日本語でいうと、「個人情報」ということになります。
身の回りには様々な個人情報が存在しており、その管理方法に関する取り決めは国によって異なっていたり、業界団体によって決まっていたりと様々です。
Twilio では、このような状況から、Twilio 上で保管されている個人情報について、どの項目をどのような基準で保存をしているかを開示しています。それが PII フィールド
と呼ばれるものです。
この記事の前半でログの内容について表を載せましたが、あの中に個人情報として規定されているものには、PII のところに120days
と記載がありました。記載のない項目については、そもそも PII フィールドではない、すなわち個人情報としては管理をしていない項目となります。
では、この120days
というのはどういうことでしょうか。
これは、MTL(Minimum Time to Live)と呼ばれ、この情報の最少生存時間です。すなわち、データが生成されると、すぐに削除したとしても最低 MTL 期間はデータは残り続けますということを意味しています。
また、削除という操作をした場合、コンソール上からはすぐに消えたように見えますが、物理的に完全に削除されるには30日かかります。
MTL を設定する目的は、Twilio がこのデータをキャリアの調整や、税務管理など、ビジネスとして利用する必要があるためです。
ちょっと例をあげて説明します。
PII フィールドとして指定されている to (相手先の電話番号)を例に取ります。
ある日に発生した通話のログは、MTL が 120days の to という項目が含まれます。このログを翌日に削除した場合、MTL が 120days なので、to の値が完全に削除されるのは121日目です。
次に120日を超えて削除した場合、たとえば、150日目に削除した場合ですが、すでに MTL 期間は終了しているため、あとは物理的に削除するための 30日が経過した、180日目に、to の値が完全に削除されます。
PII フィールドとしてマークされていないデータにつきましては、ユーザが削除することで管理コンソール上からは見られなくなりますが、内部的にはデータとして残り、統計情報などの作成に利用されます。これはそのプロジェクトが削除された場合も同様です。
以上のことからコールログについては、個人情報としてマークされているものは明示的な削除、もしくはプロジェクトの削除の場合において、MTL 期間(場合によっては+30日)を置いたのち物理的に削除されます。個人情報に該当しないデータについては、内部的には永久に残ります。
まとめ
いかがでしたでしょうか。
実は、Twilio 上にはセキュリティに関する設定項目が色々あることがわかったかと思います。
セキュリティと利便性、運用コストはそれぞれバランスが重要です。まずは皆さん側のセキュリティポリシーと照らし合わせて、最適なセキュリティ対策を実施することをおすすめします。
KDDIウェブコミュニケーションズ経由でアカウントを開設していただくと、このようなご提案も含めて最適なご相談をお受けすることができますので、これからシステムを構築される方は、ぜひ弊社経由でアカウントを開設していただけると嬉しいです(完全に営業モード)。
相談会(オンライン)は毎週水曜日に実施していますので、事前に確認したいことなどがあれば、ぜひこちらからお申込ください。
Twilio(トゥイリオ)とは
https://cloudapi.kddi-web.com
Twilio は音声通話、メッセージング(SMS /チャット)、ビデオなどの 様々なコミュニケーション手段をアプリケーションやビジネスへ容易に組み込むことのできるクラウド API サービスです。初期費用不要な従量課金制で、各種開発言語に対応しているため、多くのハッカソンイベントやスタートアップなどにも、ご利用いただいております。