セキュリティ規則と推奨事項

以下に記載するセキュリティガイドラインは、NTT CPaaSプラットフォーム内およびNTT CPaaS APIを通じて、認証やファイル転送など、最も一般的なユーザー操作を安全に実行する際の指針を示すことを目的としています。

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

NTT CPaaSアカウントを作成したら、そのNTT CPaaSアカウント (NTT CPaaS Webインターフェースとも呼ばれます) にサインインする際に、ユーザー名とパスワードが必要になります。なお、ユーザー名には特殊文字を含めることはできず、一度生成すると変更できないことにご留意ください。

パスワード管理 [#password-management-account-security]

NTT CPaaSのパスワード強度レベルは、デフォルトで「非常に高い」に設定されています。パスワードに関する一般的な要件は以下の通りです：

小文字
大文字
数字
10～50文字
記号
同じ文字を3回以上繰り返さないこと
使用可能な文字A～Z、a～z、0～9、および記号

パスワードを設定する際、アカウントを保護しやすくする、以下の重要なヒントをぜひ参考にしてください：

異なるユーザー間で同じパスワードを使用 しない こと。
他の場所、特に他のオンラインチャネル／サービスで既に使っているパスワードを使用 しない こと。
パスワードは、少なくとも四半期ごとに定期的に変更すること。
NTT CPaaSのスタッフを含め、第三者にパスワードやAPIキーを 絶対に 教えないこと。代わりに、NTT CPaaSのWebインターフェースにあるパスワード再設定フォームを利用するか、適切なインターフェースでAPIキーを管理すること。

アカウントユーザー [#account-users-account-security]

セキュリティを最大限に高めるには、アカウントのユーザー資格情報を以下の方法で管理するようにしてください：

NTT CPaaS Webインターフェイス内で、Settings (設定) → User & Teams (ユーザーとチーム) に移動します。
- 管理者ユーザーについては「アカウントマネージャー」のロールに設定したままにし、トラフィックのブロードキャスト権限を付与されているすべてのロールを削除します。その他のユーザーについては、「アカウントマネージャー」のロールを削除し、トラフィックのブロードキャスト権限を付与するロールを割り当てます。
- ユーザーのGSMとメールアドレスを検証します。
Settings (設定) → My Account (マイアカウント) に移動します。以下の一覧をリファレンスとしてご利用ください。以下のリストを参考にしてください。各設定の構成方法の詳細については、「セキュリティ設定」について詳述しているページをご参照ください。
- 2要素認証はデフォルトで有効になっており、構成可能オプションは「Remembered (記憶済み)」または「On Each Login (ログインのたびに)」です。なお、2要素認証はAPI接続に支障を来しません。
- パスワードの有効期間をセットアップします。
- 最大ログイン試行回数をセットアップします。
- ユーザーの非アクティブ日数をセットアップします。

トラフィックのセキュリティ

TLSのサポート [#support-for-tls-traffic-security]

2021年7月5日現在、当社ではTLS v1.2のみをサポートしています。以前のバージョンのサポートは終了しました。TLSバージョン1.2より低いバージョンを使用している場合、当社のプラットフォームへのリクエストを送信することはできません。現在使用しているTLSバージョンが不明な場合や、新しいバージョンへのアップグレードについてサポートが必要な場合は、サポートまでお問い合わせください。

エントリーポイント固有のユーザー [#entry-point-specific-users-traffic-security]

ユーザー資格情報は、WebインターフェースまたはAPIを通じてご利用いただけます。APIユーザーと、Webインターフェース経由でNTT CPaaSを利用するユーザーを混同しないようご注意ください。

API用 (IPセーフリストからのみアクセス可能な) ユーザーを1人保持し、残りのユーザーはWebインターフェース用に割り当てるようにすれば、接続の問題を回避しやくなります。接続の問題を引き起こさないようするには、APIユーザーはIPセーフリストに登録されたURL経由でのみAPIを利用できるようにすることが望ましいです。

トラフィックのブロードキャスト [#traffic-broadcast-traffic-security]

SMPP経由でAPIを使用する場合は、トラフィックをブロードキャストするための専用ユーザーを作成し、SSL接続を介してそのユーザーの資格情報を使ってトラフィックをブロードキャストするようにしてください。 HTTP経由でAPIを使用する場合は、ユーザーの資格情報を含むトラフィックを送信しないようにし、代わりにAPIキーをお使いください。

API接続のセキュリティを強化するには、APIキーの作成について詳述しているページで推奨されているように、APIキーまたはトークンによる認証方式を使用することをお勧めします。そうすることで、ネットワーク上のデータ転送が傍受されるリスクを軽減できます。

APIキーごとに、許可するIPアドレスのIPセーフリストを、個別のIPアドレスまたはIP範囲単位でセットアップします。NTT CPaaSのWebインターフェースから設定を行う場合は、ログインして Manage API Keys (APIキーの管理) に移動します。API経由で設定を行う場合は、APIキーの作成時にPOST APIリクエストを使用します。

以下に、使用可能なIPアドレスおよびIP範囲の例を示します：

許可されたIPリスト：192.168.1.1;192.168.1.2;192.168.1.3
IP範囲：192.168.1.0/24

SSLプロトコルを使用して、トラフィックを常に暗号化された接続経由でブロードキャストするようにしてください。

SMPP SSLエンドポイントについては、SMPP仕様について詳述しているページをご参照ください。
HTTP SSLエンドポイントについては、ベースURL について詳述しているページをご参照ください。

IPセーフリスト [#ip-safelisting-traffic-security]

IPセーフリストを使用すると、信頼できるIPアドレスまたはIP範囲のリストを作成し、そのリストに登録されたIPアドレスまたはIP範囲から、人間ユーザーやAPIがNTT CPaaSプラットフォームにアクセスできるようにすることができます。

IPセーフリストを使用する時は、以下の規約とベストプラクティスにご留意ください：

IPセーフリストは、ユーザー単位またはAPIキー単位でセットアップできます：

ユーザー単位
- セーフリストに定義されたIPアドレスは、ユーザーがWebインターフェースにログインし、それぞれの資格情報を使ってトラフィックをブロードキャストしようとする時に認識されます。
APIキー単位
- セーフリストに定義されたIPアドレスは、APIキーを使ってトラフィックをブロードキャストしようとする時に認識されます。
- APIキーのIPセーフリストは、Webインターフェース (Manage API keys (APIキーの管理)) から、またはAPI経由でAPIキーを作成する際にセットアップできます。

IPセーフリストは、特定のIPアドレスまたはIPアドレスの範囲に対して設定できます：

API - 通常、静的IPアドレスまたは企業／ISPのIPアドレス範囲を使用します。
Webインターフェース - 動的IPアドレスからのアクセスがある可能性があります (例：在宅勤務中のユーザー、モバイルネットワーク経由で接続しているユーザー、または外出中のユーザーなど)。

備考

HTTP APIキーおよびベーシック認証用のIPセーフリストは、互いに補完的な関係にあります (使用する認証方法によって、適用される制限が異なる場合があります）。

API関連のセキュリティ対策

このセクションでは、API接続のセキュリティを強化する方法について説明します。

ネットワーク経由のデータ転送が傍受されるリスクを軽減するには：

セキュリティ対策が施されていないHTTPとURLパラメーターを介したSMSを組み合わせて使用すると、ネットワーク上のデータ転送が傍受されるリスクが高いため、絶対に併用しないようにしてください。
暗号化されていない HTTP/SMPP 接続は絶対に使用せず、以下の接続に切り替えるようにしてください：
- 暗号化されたSSL/TLS接続 - セットアップが迅速で、より堅牢なフェイルオーバー機構を備えているため、このオプションが推奨されます。
- IPsec VPN接続 - 手動でのセットアップが必要であり、可用性の問題が発生した場合のインシデント管理もより複雑になるため、あまり推奨されません。これにより、お客様のプラットフォームとNTT CPaaSとの間に暗号化されたデータ通信経路が確立されます。
メッセージの送信にGETメソッドを使用しないようにしてください

パスワードの不正使用 [#password-abuse-api-related-security-controls]

パスワードの不正使用リスクを軽減するには、有効期限のあるAPIキーまたはトークンによる認証方式を使用します。

APIセッションは、最後に正常に処理されたトークンから1時間後に失効します。また、この設定はクライアントのアカウントレベルでは変更できません。

一方、APIキーはセッションレスであり、リクエストごとに送信されます。APIキーごとに有効期間を設定することができ、その期間が過ぎると、そのAPIキーは無効または期限切れと見なされます。

対策が講じられなかった場合の潜在的なリスク

暗号化されていないHTTP/SMPPトラフィックを使用する場合、トラフィックの傍受による資格情報の漏洩リスクがあります。これは、次のような状況で発生する可能性があります：

セキュリティ対策が施されていないHTTPと (Authorizationヘッダー内にエンコードされた形式でユーザー名とパスワードが含まれる) ベーシック認証を併用していた場合 - お客様のネットワーク、ISP、プロキシサービス (利用している場合) とNTT CPaaSのWebインターフェースとの間にあるいずれかのノードで発生した可能性があります。
クライアントネットワークとNTT CPaaSプラットフォームの間でMITM方式を適用していた場合。
いかなる種類のストレージ (デジタルおよびアナログ) においても、安全でない (プレーンテキスト) 形式で使用されている場合。NTT CPaaSでは、ユーザーのパスワードを一方向ハッシュ形式で保存しており、アクセス権限はごく少数の信頼できる従業員にのみ制限されています。第三者へのアクセス権は一切付与されていません。
情報交換や通信 (電子媒体や電話を介して、さらには対話形式のやり取りも含め) の際に、安全でない (プレーンテキスト) 形式で使用されている場合。
長期間パスワードを変更していない場合。

セキュリティに関する一般的な推奨事項

常に、ユーザーごとに異なる、長くて複雑なパスワードを使用するよう心がけてください。また、将来的なデータ漏洩の潜在的な原因を軽減するため、社内の資格情報の保存や管理を強化しておくこともお勧めします。
公開コードリポジトリにユーザーの資格情報をハードコーディングしないようにしてください。
トークンはパスワードと同様に扱い、秘密厳守で管理するようにしてください。API を利用する際は、トークンをプログラムにハードコーディングするのではなく、環境変数として使用することをお勧めします。

フィッシング攻撃を防ぐためにログインページの真正性を検証することも重要です。

下記の視点でURLとサイトのコンテンツに細心の注意を払うようにします：

ファビコンを確認します。ウェブサイトは、タブに任意のアイコンを表示させることができます。
ドメイン名を確認します。ドメイン名は、正規の NTT CPaaS サイトにアクセスしていることを確認するのに役立ちます。
ブラウザのアドレスバーでサイトのセキュリティステータスを確認します。ほとんどのブラウザでは、安全な ウェブサイトには、ウェブサイトのURLの左側に緑色の南京錠のアイコンが表示されます。南京錠のアイコンをクリックすると、ウェブサイトの詳細 (使用されている暗号化の種類など) を確認できます。例えば：
- ドメイン名に複数のダッシュまたは記号が含まれている場合。
- 実際のビジネスを模倣したドメイン名 (例：「inf0bip」、「infoblp」、「infob1p」)。
- 「.biz」や「.info」などのドメイン拡張子。これらのサイトは信頼できない傾向があります。
- 「.com」サイトは、本質的に信頼性が低いわけではありませんが、入手するのが最も簡単なドメイン拡張子であることにも注意するべきです。
ウェブサイトの接続方式を確認します。NTT CPaaSのWebインターフェイスが使用するウェブサイトにはhttpsタグが付いており、より一般的なhttp指定を使用するサイトよりも安全であり、信頼性が高いです。これは、大半の違法サイトが、一般的なhttpsサイトが行うセキュリティ認証プロセスをわざわざ行わないためです。
ファイルパスを確認します。NTT CPaaSのWebインターフェースでは、アクセスしたい画面に応じてファイルパスが明確になっています。パスに関してご不明な点がある場合は、サポートまでお問い合わせください。
URLを評価します。ウェブサイトのURLは、接続方式 (「HTTP」または「HTTPS」)、アプリケーション (例：「ポータル」)、ドメイン名 (例：「infobip」)、拡張子 (「.com」)、およびファイルパス (例：「/dashboard」) で構成されます。接続が安全であることを確認したとしても、以下の危険信号には常に注意を払うようにすることをお勧めします：
- ファビコン – ウェブサイトは、タブに任意のアイコンを表示させることができます。
- ドメイン名 – これはURLの一部ですが、何を検索しているのか分かっている限り、信頼できるものです。
- ファイルパス／ディレクトリ – これはURLの一部ですが、何を検索しているのか分かっている限り、信頼できるものです。
- ウェブコンテンツ領域 – これは攻撃者が望むものなら何でもあり得ます。NTT CPaaSの正規ウェブサイトを非常に巧妙に偽装したものも含まれます。
ウェブサイト上の不自然な英語表現に目を光らせます。スペルミスや単語の抜けが多数見受けられたり、全体的に文法が乱れていたり、不自然な表現があったりする場合は、そのサイトの信頼性を疑うべきです。たとえそのサイトが詐欺ではないという点で技術的には正当なものであったとしても、言語表現に不備があれば、情報の正確性にも疑念が生じ、結果として信頼性の低い情報源となってしまいます。
証明書の詳細の確認：ほとんどのブラウザでは、アドレスバーの南京錠アイコンをクリックして証明書を表示できます。

Firefoxの場合：
1. 南京錠のアイコンを選択します。
2. More Information (詳細情報) を選択します。
3. View Certificate (証明書の表示) を選択します。
Safariの場合：
1. 南京錠のアイコンを選択します。
2. View Certificate (証明書の表示) を選択します。
Chromeの場合：
1. 3ドットメニュー → More tools (その他のツール) → Developer tools (開発者ツール) を選択します。
2. Security (セキュリティ) タブを選択し、View certificate (証明書の表示) を選択します。
または
1. Certificate (証明書) → 南京錠のアイコンを選択します。
2. *Certificate Information (証明書情報) を選択すると、CAが証明書を発行する前に検証したすべての情報が表示されます。

NTT CPaaSの証明書は、次のような様式です：

機密情報の共有

このセクションでは、機密情報を安全に利用・保管する方法について、簡単に説明するクイックガイドとしてご利用いただけます。

S-PASSの使い方 [#how-to-use-s-pass-sharing-confidential-information]

S-PASS は、NTT CPaaSの従業員、顧客、およびその他の第三者と機密情報を共有するためのNTT CPaaSアプリです。共有された情報は 1回のみ閲覧可能 であり、その後S-PASSから完全に消去される点にご注意ください。

送信者からトークンを受け取っていれば、受信者に対して シークレットノートを作成して送信 したり、シークレットノートにアクセスして閲覧 したりすることが可能です。いずれの場合も、お好みのウェブブラウザを使用して S-PASS にアクセスする必要があります (ウェブブラウザによって表示が異なる場合があります）。

シークレットを保存する方法 [#store-a-secret-sharing-confidential-information]

S-PASS にアクセスします。誰かとシークレットを共有したい場合は Write a secret note (シークレットノートを書く) をクリックし、シークレットノートを読むためのトークンを受け取っている場合は Read a secret note (シークレットノートを読む) をクリックします。
送信したい シークレットノートを入力または貼り付け ます。シークレットノートを保存しておく期間を選択します。このシークレットノートは、誰かが読むか、選択した保存期間が過ぎるまで保存されます。完了したら、Store secret (シークレットを保存) をクリックします。

備考

トークンを持っている人なら誰でも、指定した期間中は作成したシークレットノートにアクセスできるようになります。

これでシークレットノートが保存されました。そのシークレットを共有するには、トークンをコピー、もしくは Secret stored! (シークレットが保存されました！) というポップアップから直接リンクをコピーします。

備考

機密情報にアクセスできるのは、トークンまたはリンクを持っている人だけです。表示されるまで、情報は暗号化され、誰にも読めず、NTT CPaaSシステムに保存されます。

シークレットを読む方法 [#read-a-secret-sharing-confidential-information]

直接アクセスリンクをお持ちの場合は、それをウェブブラウザに貼り付けると、Secret (シークレット) セクションの下に共有されているシークレットが表示されます。アクセストークンをお持ちの場合は、S-PASS にアクセスし、Read a secret note (シークレットノートを読む) をクリックして、トークンを貼り付け、Submit token (トークンを提出) をクリックします。

備考

シークレットノートは読み終わると、システムから削除されます。

安全なファイル転送

NTT CPaaSのWebインターフェースを使用すると、NTT CPaaSからレポートをどのようにエクスポートするかを定義できます。エクスポート方法としては、FTPとSFTPが利用可能です。

FTPは、暗号化されていない基本的なファイル転送機能を提供するファイル転送プロトコルです。匿名アクセスと認証済みセッションの両方を可能にしますが、ユーザーの資格情報やデータペイロードが公開ネットワーク上でクリアテキストのまま転送されるため、機密データへの不正アクセスや仕込まれたマルウェアの拡散といった 高いリスク を伴います。

FTPプロトコルは、より安全な代替手段 (SFTP、FTPS、SCPなど) に完全に置き換えられているため、極めて信頼性が高く隔離されたシステム、または匿名FTPによる公開アクセスにのみ使用すべきであり、NTT CPaaSのいかなるユースケースにも適用されるものではありません。

当社では SFTP (セキュアFTP) の使用を推奨しています。これを利用するために必要になるのは、クライアント側でSFTPサーバーを実装し、NTT CPaaSのWebインターフェースのエクスポート機能またはカスタマーケアを通じてアクセスパラメーターを提供することだけです。

セキュアな実装プロセスは、通常、以下の手順に従います：

非標準ポート (22 以外) を指定します。
インバウンド (送信者) IPアドレス範囲をセーフリストに登録します。NTT CPaaS の場合、これらは193.105.74.0/24と62.140.31.0/24となります。
各クライアントユーザーごとに専用の資格情報 (即ち、NTT CPaaS専用となる資格情報) を使用します。
長くて複雑なパスワード (12文字以上) を選択します。
パスワードは定期的に変更するようにします (例：3か月ごと)。

セキュリティ上の理由とは別に、暗号化されたデータ転送の利用は、世界中の多くの業界で、企業のセキュリティポリシーに含まれる 規制コンプライアンス要件 となっています。

セキュリティ対策が不十分なFTPバージョンを選択した場合、関連するセキュリティリスクを承知の上で利用すること を意味し、同時にNTT CPaaSは、そのような利用に起因する可能性のあるいかなる責任も負わないものとします。

NTT CPaaSリソースに対するセキュリティテスト活動の実施許可

NTT CPaaSでは、実績の豊富な外部企業を起用し、以下の内容を含むベストプラクティスの手法に基づいて、外部からの侵入テストを定期的に実施しています：

OSSTMM (オープンソースセキュリティテスト方法論マニュアル)
OWASP (オープンウェブアプリケーションセキュリティプロジェクト)
NIST (米国立標準技術研究所) が定める侵入テストおよび監査の手法。これには、対象システムのセキュリティを評価するために設計された自動と手動の両方の手法が含まれます。

NTT CPaaSでは、秘密保持契約 (NDA) の締結を条件として、契約サービスの範囲内に限り、これらのテストに関する詳細なレポートを顧客ならびにパートナーに提供しています。なお、レポートの内容や当社の脆弱性管理プログラムに関するその他の事項について、ご質問またはご相談がございましたら、当社のセキュリティチームまでお問い合わせください。

サプライチェーンのセキュリティ検証に既存のレポートや文書を活用すると、十分な保証レベルを確保しつつ、お客様と当社双方の業務負担やコストを削減できるため、有益です。

これらの説明で不十分な場合は、サービス利用規約および当該サービス契約に定められた規定に基づき、当社の環境に対する侵入テストまたは脆弱性調査を実施するよう手配することもできます。

顧客／パートナー側には、テスト結果をNTT CPaaSのコーポレートセキュリティチームと共有することに同意していただく必要があります。NTT CPaaSの製品またはサービスに関して特に深刻および／または重大な問題が発見された場合、お客様は、その発見内容を遅滞なくNTT CPaaSに報告することに同意するものとします。

重要

第三者は、NTT CPaaSおよびその関連会社に帰属するエンドポイントについて、NTT CPaaSの事前の承認なしに、いかなる種類のセキュリティテストも実施することは 認められていません。また、第三者は、事前の契約上の合意またはNTT CPaaSの承認なしに、テスト活動の結果として得られた所見、あるいはサービスの提供過程で判明した情報を、他の第三者に開示することは 許可されていません。

外部で実施するセキュリティテスト活動はすべて 事前に通知 し、NTT CPaaSの担当者 (アカウント／セールスマネージャーまたはサポート) に対して依頼を申請する必要があります。

このような依頼はすべて、当該クライアント／パートナーのテスト実施に関して与えている現行の許可に基づき審査されます。依頼が承認された場合、依頼者は、NTT CPaaS コーポレートセキュリティ部門から提供される 外部侵入テスト文書 に記載された、関与に関する所定の要件を順守する義務を負います。

当該テストで判明した脆弱性については、NDAの規定に基づき、クライアントは、その機密性を保護する責任を負う ものとします。また、いかなる形式の当該情報についても、NTT CPaaSのコーポレートセキュリティ部門による事前の承認がない限り、第三者に開示または共有してはならないものとします。

クライアントがこの守秘義務条項に違反した場合、NTT CPaaSは契約条項に基づき当該クライアントに対して責任を追及し、その際の損害賠償請求額については、当該違反行為に起因する損害の最大額を考慮して算定されるものとします。

実施された侵入テストによりNTT CPaaSシステムが脆弱であることが判明した場合、そのテスト結果はNTT CPaaSのコーポレートセキュリティ部門によって選別されます。修正が必要と判断された場合、特定された脆弱性の改修証明は、アプリケーションセキュリティを専門とする専任のエキスパートおよびその他の関連するセキュリティの専門家が取りまとめる社内向けレポートとして、依頼元の第三者に提供されます。

クライアントの内部プロセス

内部で保存・管理する資格情報に関するセキュリティ対策を強化し、将来的に発生する恐れがある内部データ漏洩のリスクを軽減することが、NTT CPaaSプラットフォームへの無断アクセスやトラフィックコストの増大を未然に防止することに繋がります。

パスワードを安全に管理するにあたり、商業グレードのパスワード管理ツールの利用をご検討ください。

資格情報の保存 (何かどのようにすべきか、またはすべきでないか）

NTT CPaaS APIをご利用される場合、パスワード、トークン、シークレットなどの機密データを扱う必要が出てくることがあります。特に、サービス処理を実行するために機密データをあるサービスから別のサービスへ送信しなければならない場合、これはかなりの難易度を伴う作業となり得ます。

機密データを保存する必要性は、正当なユースケースとなり得るものであり、設計段階では頻繁に発生する可能性があります。リソースの共有や処理の開始を安全に行う手段が確保できない場合、階層的に追加するセキュリティの仕組みを構築し、防御を多層的に強化する必要があります。

以下に、認証がハードコーディングされているシナリオのコード例を示します：

java

2 public class InfobipApp {

4 public static void main(String... args) {

5 OkHttpClient client = new OkHttpClient().newBuilder().build();

6 MediaType mediaType = MediaType.parse("application/json");

7 RequestBody body = RequestBody.create(mediaType, "{\"messages\":[{\"from\":\"InfoSMS\",\"destinations\":[{\"to\":\"41793026727\"}],\"text\":\"This is a sample message\"}]}");

8 Request request = new Request.Builder()

9 .url("https://api.infobip.com/sms/2/text/advanced")

10 .method("POST", body)

11 // The sensitive secret is hardcoded in code below

12 .addHeader("Authorization", "App 003026bbc133714df1834b8638bb496e-8f4b3d9a-e931-478d-a994-28a725159ab9")

13 .addHeader("Content-Type", "application/json")

14 .addHeader("Accept", "application/json")

15 .build();

16 Response response = client.newCall(request).execute();

17 System.out.printf("%s: %d", number, response.code());

18 }

19 }

このシナリオは、ぜひとも避けたいケースです。

それではここで、そうしたセキュリティの仕組みや機密データを安全に保護する上で有効ないくつかの方策を見ていくことにします。

ハードウェアセキュリティモジュール (HSM) を活用する

ハードウェアセキュリティモジュール (HSM) は、通常、改ざん防止機能を備えた FIPS 140-2 レベル 3 デバイスとして正式に認証された特殊な物理デバイスであり、機密情報を保存・保護し、暗号処理を安全に実行するように設計されています。HSMの基本的な考え方は、アプリケーションが展開されているコンピュータ上ではなく、より安全な環境下でデータを保存したり、処理を実行したりすることにあります。HSMのプロバイダーは数多く存在し、その使用方法や運用方法は各プロバイダーのドキュメントに記載されています。HSMの活用は、機密データを扱う上で採用できる最善のアプローチです。

機密データは絶対に保存しない

機密データを保存するのではなく、アプリケーションの導入時に対象データを組み込むようにします。そしてアプリケーションの起動時に、機密情報を要求するように設定しておきます。パスワードはメモリ内にのみ格納されるため、HSMを使用できない場合はこれが最善の対策となります。

これには他にもリスクが伴います。例えば、アプリケーションがサービスとして展開されている場合、メモリからパスワードや鍵を直接読み出すリスクや、サーバーの再起動などに起因する可用性のリスクなどが挙げられます。この方法は、他のどの方法よりもはるかに安全です。他の方法はいずれも、メモリから機密データを読み出すことに関連する同様のリスクを抱えています。　

これをシンプルなSpring Bootアプリケーションに組み込む方法を一例として以下に示します：

java

2 @SpringBootApplication

3 public class InfobipApp implements CommandLineRunner {

4 private NumberRepository numberRepository;private SensitiveData sensitiveData;

5 @Autowiredpublic App(NumberRepository numberRepository, SensitiveData sensitiveData) { this.numberRepository = numberRepository; this.sensitiveData = sensitiveData;}

6 @Overridepublic void run(String... args) throws Exception { for (String number : numbersRepository.findAll()) {

7 OkHttpClient client = new OkHttpClient().newBuilder().build();

8 MediaType mediaType = MediaType.parse("application/json");

9 RequestBody body = RequestBody.create(mediaType, String.format("{\"messages\":[{\"from\":\"InfoSMS\",\"destinations\":[{\"to\":\"%s\"}],\"text\":\"This is a sample message\"}]}", number));

10 Request request = new Request.Builder()

11 .url("https://api.infobip.com/sms/2/text/advanced")

12 .method("POST", body)// Authorization is fetched from bean and sensitive data is not stored in code

13 .addHeader("Authorization", data.getAuthorization())

14 .addHeader("Content-Type", "application/json")

15 .addHeader("Accept", "application/json")

16 .build();

17 Response response = client.newCall(request).execute();System.out.printf("%s: %d", number, response.code()); }

18 }

20 @Bean

21 public SensitiveData getSensitiveData() {Console console = System.console();SensitiveData data = new SensitiveData();data.setAuthorization(console.readPassword("Input NTT CPaaS API authorization: "));return data;

22 }

24 public static void main(String... args) throws IOException {SpringApplication.run(InfobipApp.class, args);}

25 }

機密データを保存する際に追加のレイヤーを設定する

どうしても機密データを保存しなければならない場合は、追加の防御層を設けてセキュリティ対策を更に強化すべきです。

そのための強化策として選択できる手段はいくつかあります：

シークレットを検証済みの暗号化ストア (キーストアなど) に保存し、アプリケーションの起動時にそれらのシークレットを読み込む。
シークレットを暗号化し、暗号化キーを安全に保管するとともに、そのアクセス権を当該サービスの特定のユーザーのみに限定するようにする。
シークレットを環境変数に格納し、コード内でその値をフェッチする。
認証が完了した後、アプリケーションにシークレットを提供する別のプロセスまたはサービスを使用する。

以下は、環境変数からシークレットをフェッチする方法を示すコード例です：

java

2 @SpringBootApplication

3 public class InfobipApp implements CommandLineRunner {

4 private NumberRepository numberRepository;

5 @Autowiredpublic App(NumberRepository numberRepository) {this.numberRepository = numberRepository;}

6 @Overridepublic void run(String... args) throws Exception {for (String number : numbersRepository.findAll()) {

7 OkHttpClient client = new OkHttpClient().newBuilder().build();

8 MediaType mediaType = MediaType.parse("application/json");

9 RequestBody body = RequestBody.create(mediaType, String.format("{\"messages\":[{\"from\":\"InfoSMS\",\"destinations\":[{\"to\":\"%s\"}],\"text\":\"This is a sample message\"}]}", number));

10 Request request = new Request.Builder()

11 .url("https://api.infobip.com/sms/2/text/advanced")

12 .method("POST", body)// Authorization is fetched from environment variable and sensitive data is not stored in code

13 .addHeader("Authorization", System.getenv("INFOBIP_API_AUTHORIZATION"))

14 .addHeader("Content-Type", "application/json")

15 .addHeader("Accept", "application/json")

16 .build();

17 Response response = client.newCall(request).execute();System.out.printf("%s: %d", number, response.code()); }

18 }

20 public static void main(String... args) throws IOException {SpringApplication.run(InfobipApp.class, args);}

21 }

SMS不正防止のためのセキュリティガイドライン

インターネット上でのサイバー攻撃が急増する中、ウェブアプリケーションは様々な手口で攻撃を受けています。NTT CPaaSでは、こうした攻撃を効果的に防御するため、不正利用の事例で最もよく見られるウェブアプリケーションの脆弱性を踏まえた、ウェブアプリケーションに特化したセキュリティガイドラインをお客様にご提供しています。

不正利用の事例で悪用されたウェブアプリケーションの脆弱性 [#web-application-issues-leveraged-in-fraud-cases-security-guidelines-for-sms-fraud-prevention]

不正利用の事例で悪用されたウェブアプリケーションの脆弱性

この問題に対処するために、SMSメッセージの送信頻度と件数を特定の数量に制限し、そうすることで、どのユーザーもサービスやプラットフォームを悪用できないようにします。この対策を講じると、エンドユーザーへのスパム送信を防ぎ、エンドユーザーのリソースが枯渇する事態も回避できます。レート制限はユーザーアカウント単位で実施することが望ましいです。
HTTPヘッダーとクッキーを対象としたセキュリティ対策の欠如

HTTPヘッダーには、ウェブアプリケーションに追加の防御層を設けることができる一連のセキュリティ対策の仕組みを含めるべきです。アプリケーションのクッキーには、少なくとも「Secure」および「HttpOnly」ディレクティブを設定する必要があります。さらに、追加のオプションとして「SameSite」を含めると、クロスオリジンによる情報漏洩のリスクを軽減することができます。クッキーの保護に加え、アプリケーションには、クリックジャッキング攻撃を防ぐためにX-Frame-Optionsを、XSS攻撃を軽減するためにX-XSS-Protectionを、ブラウザに HTTPSのみを使用するよう指示するために Strict-Transport-Securityなどを実装すべきです。
認証またはレート制限がない一部のAPIエンドポイント

すべてのAPIエンドポイントについて適切なアセット管理を行うことが重要です。その中にはデバッグモードまたはテストモードになっているものもあり、テスト目的で使用されるエンドポイントについては、認証やレート制限が無効になっている可能性があるためです。これは、本番環境、ステージング環境、内部環境、開発環境といった複数のデプロイメントにおいて、下位互換性を維持したい場合によく見られるケースです。
安全でない直接オブジェクト参照

アプリケーションは、データベース内の特定のオブジェクトにアクセスを試みたユーザーが、そのオブジェクトに対する適切なアクセス権を持っているかどうかを確認する必要があります。IDORは通常、ユーザーが入力内容を改ざんした場合、例えばURL内のオブジェクトIDを10から20に変更した場合などに発生します。これにより、ユーザーは別のユーザーに紐付けられたオブジェクトにアクセスできてしまう可能性があります。アプリケーションは、IDなどの実際の識別子が漏洩するのを防ぎ、代わりにハッシュを使用する必要があります。これは、連番のIDが容易に推測されてしまう可能性があるためです。
CAPTCHA機能の欠如またはセキュリティ上の脆弱性

ボット対策には、reCAPTCHAやhCAPTCHA をお使いください。ボットと人間の操作の両方によって処理される自動CAPTCHA解読ツールの存在にご注意ください。図形パズルの解き方や文脈に応じた質問など、従来とは異なるCAPTCHA手法の導入もご検討ください。
CSRF防止トークンの欠如

機密性の高いすべてのHTTPリクエストにCSRF防止トークンを使用することが推奨されています。セッションごとに生成されるCSRFトークンに比べ、悪用可能な時間が短くなるため、CSRFトークンは各HTTPリクエストごとに生成する方が望ましいです。
機密データをAPIに送信する際のGETパラメーターの使用に関する注意

機密データやAPIキーの送信には、GETパラメーターの使用を避けてください。URLは、HTTPプロキシ、ブラウザの履歴、またはウェブサーバーのログにキャッシュされる可能性があるためです。APIへ機密データを送信する際は、HTTP POSTメソッドをお使いください。
インジェクション攻撃に使用されるするペイロードなどの危険な入力のフィルタリングやサニタイズ機能を持たないウェブアプリケーション

どのような種類のデータがウェブアプリケーションの形式で使用される可能性があるかを定義します。入力データのバリデーションとエスケープ処理を実施するようにします。例えば、ユーザー名フィールドは英数字のみを受け付けるため、特殊文字を許容する必要はありません。また、電話番号フィールドでは数字のみを許可するべきです。 HTMLフォームからのユーザー入力を直接使用する代わりに、基となるデータベースとやり取りする際には、ストアドプロシージャやパラメーター化されたクエリを用いたプリペアドステートメントを使用することによって、SQLインジェクションのリスクを最小化できます。XSS対策としては、日付や「はい／いいえ」の選択など、入力形式が固定されているフォームを除き、各フォームでバリデーションと入力のサニタイズ処理を実施し、小なり記号 (<) や大なり記号 (>) などの特殊文字は常にエンコードすることをお勧めします。
安全でないHTTP経由の接続

HTTPの代わりにHTTPSに切り替えてください。そうすることで、HTTPトラフィックが暗号化され、トラフィックの傍受から保護されます。プレーンHTTPプロトコルを使用している場合、ユーザーが公共のWi-Fiホットスポットやセキュリティ対策が不十分なネットワークに接続していると、APIキーやユーザーの資格情報が悪意のある第三者に盗聴される可能性があります。SSL 2.0/3.0の使用を避け、TLS 1.0を無効にし、TLS 1.2およびTLS 1.3をお使いください。また、nullおよび匿名暗号スイートを無効にしてください。
不十分なログ記録と監視

ウェブアプリケーションは、保存時および転送時に適切なレベルの完全性を保ちつつ、十分な量のログを生成できる必要があります。また、アプリケーションのログからは、プレーンテキストの資格情報やメッセージ内容などの機密情報がサニタイズ処理によって削除される必要があります。これは特に、認証や登録、パスワード／APIキーの変更、アクセス拒否、入力検証エラーなどの機密性の高い操作において重要です。ログの記録と監視は、将来的なフォレンジック調査やユーザーの行動の検証を行う上で必須の要件となります。