Twilioのセキュリティ対策とお客様が取れるセキュリティ対策

Twilioはサービスを提供するにあたり、セキュリティ対策は非常に大切なファクターだと位置付けています。
本ブログでは、Twilioの実施しているセキュリティ対策とお客様がTwilioを利用する上で実施可能なセキュリティ対策についてご紹介いたします。

• TwilioとKDDIウェブコミュニケーションズが取得している認証について
• Twilioのセキュリティ対策
• お客様がTwilioを利用する上で実施可能なセキュリティ対策

TwilioとKDDIウェブコミュニケーションズが取得している認証について

Twilioでは機密性の高い情報を多く扱うことから、多種多様なセキュリティ認証を取得しています。

Twilioが取得しているセキュリティ認証

ISO 27001

「ISO27001」は、情報セキュリティマネジメントシステム（ISMS）に関する国際規格です。
情報の「機密性」、「完全性」、「可用性」の3つをマネジメントし、情報を有効活用するための組織の枠組みです。

ISO 27017

「ISO27017」は、クラウドサービスの提供や利用に対して適用されるクラウドセキュリティの認証です。

ISO 27018

「ISO27018」は、クラウドサービス事業者がパブリッククラウド上で管理する個人情報保護に関する国際規格の認証です。

PCI for Voice

「Payment Card Industry Data Security Standard（PCI DSS）」とはクレジットカード会員データを安全に取り扱う事を目的として策定された、クレジットカード業界のセキュリティ基準です。
Twilio Programmable Voiceでは電話を用いて決済できるサービスを提供しています。

Privacy Shield

「Privacy Shield」は当該企業が個人情報の利用・保存・さらなる移転に関する強力な個人情報保護ルールと保護条項に則っていることを条件に、EUから米国にある企業への個人情報の移転を認めるものです。

Cloud Security Alliance

Cloud Security Alliance（CSA）は安全なクラウドコンピューティング環境を確保するためのベストプラクティスの定義と認識の向上に取り組む世界をリードする組織です。TwilioはCSAに検証されたサービスとして登録されています。

SOC 2 for SendGrid & Authy

SOC 2 は、AICPA の既存のトラストサービスの原則と基準に基づいたレポートです。SOC 2 レポートの目的は、セキュリティ、可用性、処理の整合性、機密性保持、プライバシーなどに関して組織の情報システムを評価することです。

GDPR

General Data Protection Regulation（GDPR）は欧州議会、欧州理事会および欧州委員会が策定した個人情報保護の枠組みです。

KDDIウェブコミュニケーションズが取得しているセキュリティ認証

ISO 27001

「ISO27001」は、情報セキュリティマネジメントシステム（ISMS）に関する国際規格です。情報の「機密性」、「完全性」、「可用性」の3つをマネジメントし、情報を有効活用するための組織の枠組みです。

Twilioのセキュリティ対策

Twilioが提供している英語のホワイトペーパーを日本語に意訳し、Twilioのセキュリティ対策をご紹介いたします。

日本語版ホワイトペーパーのダウンロードは、以下フォームよりお申し込みいただけます。
※こちらの日本語ホワイトペーパーは、参考のための抄訳および参考訳であり、その内容を保証するものではありません。原文である米国Twilio社のホワイトペーパーを併せてご参照ください。

セキュリティ管理部門とプログラム

セキュリティは全てのチームにとって最優先事項ですが、専任のセキュリティチームがTwilioのセキュリティプログラムを管理しています。 Twilioのセキュリティフレームワークは、ISO 27001情報セキュリティ基準に基づいており、以下を含んでいます。
対象プログラム：

• ポリシーと手順
• 資産管理
• アクセス管理
• 暗号化
• 物理的セキュリティ
• 運用セキュリティ
• 通信セキュリティ
• ビジネス継続性セキュリティ
• 人に関するセキュリティ
• 製品に関するセキュリティ
• クラウドとネットワークインフラストラクチャに関するセキュリティ
• セキュリティコンプライアンス
• サードパーティーセキュリティ
• 脆弱性管理
• セキュリティの監視
• インシデントレスポンス

セキュリティは企業にとって最も重要な指標で、Twilio社内の情報セキュリティチーフや経営層と定期的に議論を行い、全社に渡るセキュリティに関する啓蒙活動へと繋げています。これら情報セキュリティポリシーや基準は経営層に承認され、全てのTwilio社員に適用されます。

人に関するセキュリティ

Twilioは人によって作成されるため、人材はTwilioにとって非常に重要です。Twilioでは適切な人材を確保し、セキュリティトレンドを最新の状態に保つための施策を実施しています。

以下Twilioで実施している施策をご紹介いたします。

バックグラウンドチェック

米国での全ての採用候補者は、採用前に第三者専門機関による厳格な身元調査に合格する必要があります。米国内の場合、社会保障番号（ソーシャルセキュリティナンバー）履歴、過去7年の州内での犯罪履歴および州を跨いだ軽犯罪歴、性犯罪歴、OFAC規制、専門性に対する背景の裏付けや学歴の裏付けなどが調査の対象となります。 また米国外の新入社員の場合は、国際的な犯罪歴と学歴詐称の有無が調査の対象となります。

情報セキュリティトレーニング

Twilioの全ての新入社員は、入社研修で"Security 101" プログラムを受講します。 さらに、Twilioの全従業員は、情報セキュリティポリシー、セキュリティのベストプラクティス、プライバシーポリシーを対象とした、Twilioのセキュリティとプライバシーのトレーニングを年に1回受ける必要があります。

継続的な教育活動

Twilioセキュリティチームは、新たな脅威に関する継続的なコミュニケーションを提供し、フィッシング認識キャンペーンを実行し、定期的に会社とコミュニケーションをとっています。

倫理ホットライン

Twilioは、従業員が非倫理的な行動を報告するための匿名のホットラインを準備しています。 ※Twilioの従業員は、匿名の報告が合法である地域の問題を匿名で報告できます。

製品に関するセキュリティ

Twilio Product Securityプログラムの使命は、Productチームがセキュリティに関して最高クラスのソリューションを構築できるようにすることです。

アプリケーションのセキュリティ基準とガイドライン

Twilio Security Development Lifecycle（TSDL）は、安全な製品を作成するプロセスと、Productチームが開発のさまざまな段階（要件、設計、実装、および展開）で実行する必要がある活動を定義します。

安全な設計

Twilioのセキュリティエンジニアは、当社の製品が安全であることを保証するために、次のような活動を継続的に行っています。

• 製品ローンチ前のセキュリティ内部レビュー
• 第三者による定期的なペネトレーションテスト
• 継続的なバグ検出報奨金プログラム
• 継続的な内部/外部 からのセキュリティテスト
• 脅威モデルの管理

セキュリティ文化の構築

Twilioでは、ソフトウェアセキュリティトレーニングを実施しています。トレーニング資料は社内で開発されており、開発者がこれらのトレーニングを最大限に活用できるようにTwilioに特化して作成されています。 すべての開発者は、理解度を確認するために最終テストに合格する必要があります。また、セキュリティチームの取り組みを拡大するために、開発チームにセキュリティチャンピオンを配属しています。

変更管理

Twilioには、すべての変更が追跡および承認される正式な変更管理プロセスがあります。変更はステージング環境に移動する前にレビューされ、ステージング環境で本番環境にデプロイされる前の最終的なテストが行われます。

通信の暗号化

TwilioはTLS 1.0、1.1、1.2をサポートしており、お客様のアプリケーションとTwilio間のネットワークトラフィックを暗号化します。

ペネトレーションテスト

Twilioは定期的にサードパーティの侵入テストを実行します。さらに、当社のバグ報奨金プログラムは、継続的なテストとセキュリティコミュニティからの脆弱性の責任ある開示を奨励しています。

アカウントのセキュリティ

Twilioは、クレデンシャルを保存する前にソルト化し、繰り返しハッシュする業界のベストプラクティスの方法を使用して、秘密を保護します。 お客様は、Twilioコンソールに2要素認証（2FA）を使用して、アカウントにセキュリティの別のレイヤーを追加することもできます。

Twilio Security Development Lifecycle

Twilioの開発者は、製品の開発中にTwilio Security Development Lifecycleに従い、製品の設計、開発中、および展開後の安全を確保します。

クラウドインフラストラクチャに関するセキュリティ

インフラストラクチャとネットワークのセキュリティは重要です。Twilioアプリケーションと顧客のイノベーションのための安全なプラットフォームを作成することが、当社のクラウドセキュリティプログラムの使命です。 Twilio's Cloud Security Standard（TCSS）は、最高クラスのセキュリティプラクティスで構成されています。私たちは、独自基準のベースとなっているセキュリティポリシーフレームワークをオープンソースにしています。 TCSSのすべての要件は、4つの主要な原則によって推進されます。

資産管理と所有権

すべてのクラウド資産には、決まった所有者、セキュリティ分類、および目的が必要です。

インフラストラクチャマネージメント

インフラストラクチャ、ネットワーク、データへの直接アクセスは可能な限り最小限に抑えられています。 運用環境で実行されているサービスは、可能であればコントロールパネル等を用意し、インフラストラクチャ、ネットワーク、およびデータへの直接アクセスを削減します。本番リソースへの直接アクセスは、アクセスを必要とする従業員に制限されており、承認、強力な多要素認証、およびbastionホストを介したアクセスが必要です。

多層防御策

Twilioの本番環境は、論理的に分離されたVirtual Private Cloud（VPC）構成となっており、顧客データと顧客向けアプリケーションが置かれています。本番環境とステージング環境は分離されています。本番環境へのネットワークアクセスは、ファイアウォールを使用して制限され、許可されたサービスのみが運用ネットワークでアクセスできるようにします。

Twilio規格のネットワーク監視

Twilioは、リスクの高いアクションと本番環境の変更をログに記録します。ログの監視は自動化しており、設定された基準から逸脱したログが発見された場合、数分以内に問題を通知します。

継続的な監視と脆弱性の管理

Twilioでは、Productとインフラストラクチャのセキュリティと復旧力を最優先事項としています。継続的な監視は、「secure by design」の思想に基づいています。 継続的な監視は、Twilioプラットフォームのインシデントを予防および検出する機能を設計するためのプロセスと手順を開発します。 脆弱性の管理は、Twilioプラットフォームに対する脆弱性を特定、対応、およびトリアージする方法を確立します。 プラットフォームのセキュリティを確保するため、Twilioは引き続き次の機能を成長させています。

継続的な監視

Twilioは、脆弱性の予防および探知機能の開発を通じて継続的な監視に取り組みます。脆弱性、インシデント、脅威に対する継続的な意識を通じて、Twilioはそれに対応する体制を整えています。

インシデント対応

Twilioは、NIST SP 800-61に従ってインシデント対応を行っています。ここでは、セキュリティインシデントが分類およびトリアージされる条件が定められています。Twilioセキュリティインシデントレスポンスチームは、関連するすべての脆弱性またはセキュリティインシデントの脅威を評価し、すべてのイベントの修正および軽減するアクションを確立します。

セキュリティログの保持

セキュリティログは保持されます。これらのセキュリティログへのアクセスはTwilioセキュリティインシデントレスポンスチームに制限されています。

DDoS対策

セキュリティインシデントチームは業界最先端のプラットフォームを活用してDDoS攻撃の検知、対策、防衛策を実施しています。

物理的セキュリティ

物理的なセキュリティは、Twilioのセキュリティ戦略の重要な部分です。データセンターやオフィスのセキュリティ対策にも取り組んでいます。

データセンターのセキュリティ

Twilioは、すべての本番環境と顧客データにAWSデータセンターを活用しています。AWSは業界のベストプラクティスに従い、また、準拠しています。 AWS Data Centerの物理的セキュリティの詳細については、AWSセキュリティホワイトペーパーを参照してください。

オフィスのセキュリティ

Twilioには、オフィス全体のセキュリティを管理するセキュリティプログラムがあります。すべての従業員、請負業者、訪問者は、それぞれの役割を区別する識別バッジを着用する必要があります。

ビジネス継続性及び災害復旧

Twilioは、さまざまなツールとメカニズムを使用して、最高クラスの復旧力を保証します。

リカバリープラン

Twilioは、定期的にリカバリープランの見直しを行い、ビジネス継続性および災害復旧計画を維持しています。

グローバルな復旧力

AWSでサービスをホストすることにより、Twilioは、1つのリージョンがダウンしても、グローバルに復旧力を維持することができます。 AWSは複数の地理的リージョンとアベイラビリティーゾーンにまたがっており、Twilioサーバーは、自然災害やシステム障害など、ほとんどの障害モードの発生時に復旧力を維持できます。

顧客データのバックアップ

Twilioは、Amazon S3クラウドストレージを使用して、Twilioアカウント情報、通話記録、通話録音、その他の重要なデータの定期的なバックアップを実行します。 すべてのバックアップは、送信中および保存時に強力な暗号化を使用して暗号化されます。バックアップファイルは、複数のアベイラビリティゾーンにわたって冗長的に保存され、暗号化されます。

サードパーティーセキュリティ

相互に関連するビジネス環境では、ソフトウェアサプライチェーンの可視性を維持することが最も重要です。 Twilioは次の施策を実施しています。

審査プロセス

Twilioが使用するサードパーティは、採用前に評価され、サードパーティがTwilioのセキュリティ要件を満たしていることを検証します。

継続モニタリング

サードパーティーを採用後、Twilioはセキュリティとビジネス継続性を定期的に確認します。 モニタリングは、アクセスのタイプとアクセスされるデータ（存在する場合）の分類、データを保護するために必要な制御、および法的/規制要件を考慮します。

解約

Twilioは、ベンダー関係の終了時にデータ返却/削除することを保証します。

セキュリティコンプライアンス

Twilioはリスクを軽減し、Twilioサービスが規制とセキュリティを確実に満たすように努めています。

規制環境への適合

各種法規制に遵守した上、業界要件に対してベストプラクティスで適合するよう努めます。

一流インフラプロバイダの選定

Twilio のコミュニケーションプラットフォームは、高可用・高信頼 かつ 安全な AWS のデータセンターへホスティングされています。AWS は SSAE16、SOCフレームワーク、ISO 27001、PCI DSS等、高いセキュリティ基準を満たして運営されています。

ISO 27000シリーズ

Twilioは、ISO / IEC 27001：2013認証を取得しており、高いセキュリティを誇っています。 セキュリティはTwilioの最優先事項であり、この実績は、情報セキュリティ、データ保護、および継続的な改善への取り組みを示しています。

EU - U.S. Privacy Shield Framework

EU圏から米国へお客様の個人情報を転送する際は、EUデータ保護要件を遵守します。また、Twilio社の取り組みの一環として、プライバシーシールドの下で自己認証を行っています。

SOC2 TYPE II

Authy（Twilioによる2要素認証）は、Trust Services Principles of Security and AvailabilityのSOC2 Type II監査を完了しました。

Twilioの強み

Twilioプラットフォームは、音声、ビデオ、メッセージングを顧客向けアプリケーションに簡単に組み込むことで、企業が優れた顧客体験を提供できるようにします。

プラットフォームの物理コンポーネント、ネットワークコンポーネント、およびアプリケーションコンポーネントを保護するセキュリティメカニズムと、セキュリティプラクティスおよびコンプライアンスのベストプラクティスに関する透明性を組み合わせることで、通信をクラウドに移行する必要があるという確信を顧客に提供します。 Twilio搭載アプリケーションを保護するための詳細と手順については、APIドキュメントのセキュリティページをご覧ください。

お客様がTwilioを利用する上で実施可能なセキュリティ対策

ここからは、お客様がTwilioを利用する上で実施可能なセキュリティ対策についてご紹介いたします。

APIセキュリティ

Twilioではお客様のAPIへの不正アクセス防止の方法として、以下対応を推奨しております。

• HTTP認証と暗号化の併用
• Twilioからのリクエスト認証フローの追加

HTTP認証と暗号化の併用

TwilioはTwilioとアプリケーション間の暗号化された通信をサポートしており、HTTPS URLを使用することができます。

TwilioはBasic認証とダイジェスト認証をサポートしており、TwiMLを返却するWebサーバーをパスワードで保護することができます。TwilioではHTTP認証と暗号化を使用することを強く推奨しています。

ユーザー名とパスワードは、以下のURL形式で入力できます。

https://username:password@www.myserver.com/my_secure_document

詳細についてはこちらをご覧ください。

Twilioからのリクエスト認証フローの追加

Twilio以外のリクエストからお客様のAPIを守るために、Twilioからのリクエストかどうかを検証する仕組みを提供しています。
Twilioはお客様のAPIへのリクエストに対し暗号化した署名をHTTPヘッダー（X-Twilio-Signature）で送信します。お客様はこのHTTPヘッダーを検証することでTwilioからのリクエストか、それ以外からのリクエストか判断することが可能です。

実際にPHPを用いて実装方法についてご紹介いたします。

別の言語での実装方法はこちらをご覧ください。

<?php
    // このサンプルはTwilio helper libraryを利用します
    // 詳細については以下をご覧ください。
    // https://jp.twilio.com/docs/libraries/php
    require_once '/path/to/vendor/autoload.php';
    
    use Twilio\Security\RequestValidator;
    
    // Auth Tokenを設定します
    $token = 'your auth token';
    
    // HTTPリクエストのヘッダーから「HTTP_X_TWILIO_SIGNATURE」を取得します
    $signature = $_SERVER["HTTP_X_TWILIO_SIGNATURE"];
    
    // validatorを初期化します
    $validator = new RequestValidator($token);
    
    // TwilioがリクエストしてきたURLを取得します
    $url = $_SERVER['SCRIPT_URI'];
    
    // TwilioがPOSTしてきたBodyを取得します
    $postVars = $_POST
    
    if ($validator->validate($signature, $url, $postVars)) {
        echo "Confirmed to have come from Twilio.";
    } else {
        echo "NOT VALID. It might have been spoofed!";
    }
 

不正利用対策

Twilioではお客様を保護するため、Twilioの通信プラットフォームの不正利用を予防措置的かつ自動で検出するためにデザインされた内部システムを備えています。不正利用を検出した場合、影響を受けたお客様にただちにご連絡しています。
ただ、Twilioはプログラマブルな通信プラットフォームなので、新手の詐欺の手口を開発される可能性があります。お客様も不正利用の手口を知り、対策を行う必要があります。

ここからは国際的に起きている不正利用の手口と、不正利用の対応策をご紹介いたします。

最新情報はこちらをご確認。

アカウントの保護

アカウントの不正利用を回避するために、以下対応を推奨しています。

パスワードマネージャーを用いたパスワード管理

パスワードマネージャーを用いることで複雑なパスワードを生成して暗号化し、安全に保存して、必要なときに使用できるようにすることができます。

特定のパスワードマネージャーを推奨するのは難しいですが、こちらのリストに乗っているものを推奨しています。

二要素認証の有効化

二要素認証（2FA）は、ID/パスワードの検証と携帯端末の認証により、お客様を検証します。これを行うことでID/パスワードを用いてアカウントに不正アクセスされることを防ぎます。

トークン情報の隠蔽

Account SIDとAuth tokenを知っている人は、誰でもTwilioへリクエストを発行できてしまいます。そのため、トークン情報は環境変数を利用し厳重に保護してください。各環境での環境変数利用方法はこちらをご覧ください。
token情報が公開されてしまった可能性がある場合、更新方法を参照し直ちにトークン情報を更新してください。

地理的な発信制限の設定

Twilioの利用が着信のみを必要とする場合は、発信許可を無効にすることをお勧めします。また、電話を発信する場合は、必要な国だけに発信を制限し、他の国はすべてブロックすることをお勧めします。地理的な発信制限の設定はこちらから設定することができます。

地理的なSMS発信制限の設定

地理的な発信制限と同様に、Twilioの利用でSMSメッセージを送信する必要がない場合、TwilioコンソールでSMSの地理による使用許可を全て無効にすることによって、アカウントのSMS発信を無効にすることができます。

利用限度トリガーの使用

利用限度トリガーを設定すると、設定条件が満たされた場合に、指定したコールバックURLへのwebhookを送信することができます。たとえば、1 日の課金額が30,000円を超えた場合は利用限度トリガーを発動させて、サブアカウントを一時停止することができます。

利用制限トリガーAPIの利用方法についてはこちらをご覧ください。
サブアカウントのサスペンド方法はこちらをご覧ください。また、一時停止できるのはサブアカウントに限ります。

アプリケーションの保護

アカウントを保護したら、次はアプリケーション自体を保護する必要があります。ここからは、発生する可能性がある不正利用の事例と防御策について、製品ごとに分類して説明します。

Programmable Voice

Programmable Voiceに関連して最も目にする不正利用は、トラフィックポンピングとして知られているトラフィックの不正釣り上げです。Twilio のプラットフォームからお客様のアカウントで通話を発信するこれらの不正利用は、国際キャリアやプレミアムレート番号（PRN）など、不正利用者が所有する利用料金の高い宛先に、コールトラフィックを転送します。

トラフィックポンピングは、自動音声録音が通話に応答して、この通話が不正利用であることが気付かれないように、会話を続けるか、単純に無音になります。キャリア（不正利用を認識しているかどうかは不明）は、その番号への通話によって生み出される利益を不正利用者と山分けします。不正利用された料金は、発信番号の所有者に請求されます。したがって、番号の所有者が不正利用の被害者になります。

不正利用の手口

トラフィックポンピングに利用されるアプリケーションの脆弱性の例を次に示します。

サインアップフロー

不正利用者はお客様のアプリケーションにて複数のアカウントを作成します。それらを利用して国際通話を発信するアクセス権限を取得し、お客様のTwilioアカウントで通話を発信します。

アカウント認証

Twilioを使用して、音声認証による二要素認証を実装している場合、不正利用者の電話番号に認証を行うことでトラフィックポンピングに利用される可能性があります。

トールフリー

不正利用者がお客様のトールフリー番号に対してトラフィックポンピングを行った場合に発生します。これにより、通話に含まれる1つまたは複数のキャリアから利益を得ることができます。また、この手法はお客様を困らせて、特定の番号を手放させるために使用する場合もあります。

不正利用の対応策

フォームへの入力値の検証

フォームに入力された電話番号を検証することで、想定していない電話番号を入力できないようにします。国発信コードと通話プレフィックスでフィルタリングすることによって、そのような番号の入力を防止できます。

Twilio Authy 2FAの利用

ユーザーのログイン情報は、さまざまな理由で漏洩する可能性があります。アプリケーションの開発者はそれをどうすることもできません。しかし、アプリケーションがAuthy 2FAを実装している場合は、ユーザーログイン時に、不正利用者がアクセスできないユーザーのモバイル機器という2番目の要素が必要になります。

送信制限を実装する

アプリケーションで、Twilioに送信する通話リクエストのペースを制御できます。たとえば、nginxを使用して送信を制限することができます。また、Stack Overflowの記事では、Pythonで送信制限アルゴリズムを実装する方法について議論しています。

SIPトランク

PBXでTwilioのSIPトランクを使用している場合、最も目にする不正利用は、PBXハッキングが原因です。不正利用者は、不正利用を行うために、まずPBXをハッキングして、PBXへのアクセスを取得する必要があります。たとえば、PBX上のポートをスイープして、開いているポートを利用してシステムに侵入します。また、PBXからSIPクレデンシャルを取得して不正利用する場合もあります。

不正利用の手口

トラフィックポンピング

PBXに侵入した不正利用者は、PBXを再設定して国際通話発信の制御を取得します。これにより、このPBXからトラフィックポンピングを発信できるようになります。この不正利用のシナリオは、コールトラフィックの発信元がTwilioアプリケーションではなくPBXであるという事実を除けば、上述の「Programmable Voice」で説明した手口に似ています。これらの手口では、不正利用者はTwilioアカウントから不正利用者が所有する料金の高い宛先に大量のコールトラフィックを送信します。

通話の転送

不正利用者は、PBXへのアクセスを取得するとすぐに、料金の高い宛先への通話転送を設定します。次に、このPBXへの通話を生成します。すると、Twilio SIPトランクによって自動的に、それらが料金の高い宛先に転送されます。

マルチ転送

これは、さらに高度な形式の通話転送攻撃です。この場合、料金の高い宛先に転送された通話は、PBXによって次に料金の高い宛先に転送されます。この接続は Twilio によって管理され、お客様のアカウントに請求されます。この通話は、最大4時間アクティブに維持された後、自動的に終了します。不正利用者はこれを繰り返すことによって、数百～数千の通話を生成できます。

中間者攻撃

音声通話は、メディアとしてRTPプロトコルを使用します。攻撃者が侵入した場合、RTPストリームの複製を自分の目的のために透過的にストリーミングできます。

Telephony denial of service（TDoS）

コールセンターアプリケーションを運用している場合、攻撃者が膨大な量のトラフィックをその番号に送信してシステムを停止させ、正当な通話を受信できないようにすることができます。

不正利用の対応策

PBXのセキュリティのベストプラクティスを実施する

• デフォルトのパスワードを利用しない。
• PBXをファイアウォールで保護し、不要なポートをすべて閉じる。
• PBXの管理作業はすべてHTTPS経由で実行する。

SIP セキュリティのベストプラクティスを実施する

詳細については、こちらをご覧ください。

• SIP資格情報を持つIP許可リストを使用する。
• SIPシグナリングのTLSを有効にする。
• メディアトラフィックのSRTPを有効にする。
• 詳細で説明されているセキュアなアプリケーションデザインを実践する。

SIPアラートトリガーを使用する

トリガーを使用することで、疑わしい方法でシステムを操作した場合にアラートを送信するようにできます（トリガーを設定できるエラーの完全なリストについては、こちらをご覧ください）。
主要な怪しいエラー

• 32201：SIP：ソース IP アドレスが ACL にありません
• 32202：SIP：不正なユーザークレデンシャル
• 32203：SIP：ブロックされた電話番号

TDoS 緩和策を採用する

これらの製品は、TDoS によってサービスが中断しないように設計されています。特定の製品を推奨することはできませんが、複数のベンダーから多くの製品が提供されています。

Programmable SMS

Programmable SMSで最も目にする不正利用はフィッシングです。フィッシングメッセージは、受信者の取引銀行、小売店、または友人から送信されたように見える偽のSMSメッセージであり、信頼できるソースから来たように装うことができます。

不正利用の手口

発信フィッシング

お客様のアプリケーションがハッキングされた場合、発信スパム/フィッシングメッセージを被害者に送信するために使用される可能性があります。またはアプリケーションがユーザーに任意の番号を入力して任意のメッセージを送信することを許可している場合、不正利用者は簡単にフィッシングを実行できます。

受信フィッシング

お客様のアプリケーションでSMSのやりとりを許可している場合、不正利用者は送信相手にハイパーリンクまたは電話番号が記載されているメッセージを送り込むことができます。メッセージ受信者がハイパーリンクをクリックするか、または電話番号に発信すると、被害者になる可能性があります。

不正利用の対応策

ログインにAuthy 2FAを用いる

ユーザーのログイン情報は、さまざまな理由で漏洩する可能性があります。アプリケーションの開発者はそれをどうすることもできません。しかし、アプリケーションがAuthy 2FAを利用している場合は、ユーザーログイン時に、不正利用者がアクセスできないユーザーのモバイル機器という2番目の要素が必要になります。

送信制限を実装する

Programmable Voiceを送信制限できるのと同様に、アプリケーションへのメッセージトラフィックを送信制限できます。たとえば、nginxを使用して送信を制限することができます。また、Stack Overflowの記事では、Pythonで送信制限アルゴリズムを実装する方法について議論しています。

任意の番号へのメッセージング機能を作らない

お客様のアプリケーションでユーザーに任意の番号の入力を入力させないようにします。アプリケーションにこの機能が必要な場合は、その番号に任意のメッセージを送信できないようにします。

やりとりしているメッセージからハイパーリンクまたは電話番号、あるいはその両方を削除する

やりとりしているメッセージからコールツーアクションが削除され、フィッシングに使用できなくなります。

電話番号

実際行われていますが、あまり目にしない不正利用が、Twilioの電話番号を不正に転出する不正利用です。これは、スラミングとも呼ばれます。

不正利用の手口

スラミング（内部）

不正利用者は、ユーザーが所有する高い価値のある番号を盗むために、ユーザーの Twilioアカウントへの不正なアクセスを取得します。次に、ユーザーに気付かれないように、この番号を別のキャリアに転出します。これで、不正利用者はこの番号を別の人に販売できるようになります。ユーザーのアプリケーションでこの番号への依存性がハードコードされている場合、アプリケーションで提供するサービスが停止する可能性があります。

スラミング（外部）

不正利用者は、Twilio アカウントにアクセスしなくても、番号を転出できます。この場合、不正利用者は、特定の番号が欲しいことを番号転出先のキャリアに通知します。不正利用者が番号転出先のキャリアから署名入りの LOA （Letter of Authorization：認可書）を入手（なりすまし）して、そのキャリアの登録ユーザーであることを示すことができた場合、そのキャリアが転出を実行できます。このキャリアは、転出について、ユーザーまたは Twilioに通知する義務を負わない場合があります。

不正利用の対応策

アカウントの保護

アカウントが厳重に保護されていることは、不正なアクセスや転出の防止に役立ちます。詳しくは上記のアカウントの保護をご覧ください。

番号をハードコードしない

ユースケースによっては、特定の電話番号に明示的に依存しないでアプリケーションを実装するさまざまな方法があります。以下、プロダクト別に対応策をご紹介いたします。

SMS

SMS メッセージを発信するには、メッセージングサービスを使用します。この場合、特定の Twilio番号を使用してメッセージを送信するのではなく、番号のプールを設定したメッセージングサービスを使用してメッセージを送信します。

Voice

アプリケーションが発信する場合、TaskRouterを使用して番号のプールを管理できます。たとえば、プールに含まれる番号ごとにワーカーを作成します。発信する必要があるときは、タスクを作成します。TaskRouterは、タスクに使用できるワーカー（番号）を見つけて予約し、その番号を含むwebhookをシステムに生成します。次に、Calls APIを使用して、その番号に発信します。予約が受諾されると、ワーカーは使用可能になり、番号が解放されて、以降の通話で使用できるようになります。（詳細については、「TaskRouter API Reference」をご覧ください）。

不正利用が疑われた場合

不正利用が疑われた場合にはいち早く対応する必要があります。ここでは対応内容についてご紹介いたします。

お問い合わせ

不正利用が疑われた場合、すぐにこちらまでお問い合わせください。

アカウントを一時停止または閉鎖

アカウントが一時停止されている場合、そのアカウントを使用して通話やSMSメッセージを発信または受信することはできません。一時停止したアカウントは、必要に応じて後で再度有効にすることができます。マスターアカウントを一時停止または閉鎖するには、サポートにお問い合わせください。

パスワードの変更

パスワードを変更することによって、不正なユーザーによるアクセスをブロックできます。所有者以外のユーザーがそのアカウントに対するアクセス権を持つ場合、それらのユーザーのパスワードも変更してください。

トークンの更新

ユーザーのアカウントを利用して発信またはメッセージの送信を行っている場合、認証トークンが漏洩している可能性は非常に高いです。新しい認証トークンを発行してください。

APIキーの削除

認証トークンで作成した API キーは、無効にするか、削除してください。

番号への着信をブロック

着信トラフィックポンピングの被害者は、不要な音声通話を受信し続けます。着信及びSMSのブロックを行ってください。

Enterprise Edition

Enterprise Editionを利用することでセキュリティを向上させることができます。

Enterprise Editionのご利用ついてはこちらよりお問い合わせください。

Audit Event

フルマネージドな変更ログとSIEMに対応したAPIによってセキュリティーホールを防ぎ、パスワード変更等の操作が「いつ」「誰に」「どのように」変更されたのかを追跡することができます。また、ログイン履歴も閲覧が可能となります。

Static Proxy

Voice、SMSのTwiMLリクエストとTaskRouterのWebhookが、固定IPを持つTwilioゲートウェイを経由してお客様のサーバにアクセスします。

Public Key Validation

APIを詐称などによるハッキング⾏為から保護します。お客様が作成した公開鍵を使⽤し、APIリクエストが承認済みのアプリケーションからのものであることをTwilioが常に検証します。

SSO

ユーザーにとって便利で⼀貫性のある⼿段でTwilioにログインできます。SAMLベースのSSOを使⽤し、お客様のID管理システムでTwilioへのログイン可否をコントロールできます。

Phone Number Redaction

SMSを送信する際に宛先電話番号の末尾4桁をマスクした上でログに保存することで、ユーザの個⼈情報を保護します。

Message Body Redaction

SMSを使って機密情報などを送信する場合に、メッセージ内容をマスクした上でログに保存することで情報漏洩のリスクを軽減します。

脆弱性の報告

Twilioではバグの発見に報奨金プラットフォームを利用して、潜在的な問題やTwilioサービスの改善方法を特定も行っておいります。脆弱性が見つかった場合にBugcrowdを通じてご報告いただくと、報奨の対象となります。

脆弱性のご報告はこちらから！