Logo
エッセンシャルズ
アカウントを管理する
セキュリティ規則と推奨事項

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

以下に含まれるセキュリティ ガイドラインは、Infobip プラットフォーム内および Infobip API を使用して、認証、ファイル転送などの最も一般的なユーザー アクションを安全に実行できるようにすることを目的としています。

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

Infobip アカウントを作成し (opens in a new tab)たら、ユーザー名とパスワードを使用して Infobip アカウント (Infobip Web インターフェイスとも呼ばれます) にサインインします。ユーザー名に特殊文字を含めることはできず、一度生成すると変更できないことに注意してください。

パスワード管理

Infobip のパスワード強度は、既定で非常に強力に設定されています。一般的なパスワード要件は次のとおりです。

  • 小文字
  • 大文字
  • 数
  • 10 から 50 文字
  • 記号
  • 3+繰り返し文字なし
  • 使用できる文字 A から Z、a から z、0 から 9、および記号

アカウントを保護するために、次の重要なパスワードのヒントを参考にしてください。

  • **** 異なるユーザーに同じパスワードを使用しないでください。
  • **** 他の場所、特に他のオンラインチャネル/サービスで使用するパスワードは使用しないでください。
  • **** パスワードは定期的に、少なくとも四半期ごとに変更してください。
  • **** パスワードや API キーを Infobip スタッフを含む第三者と共有しないでください。代わりに、Infobip Web インターフェイスのパスワード リセット フォームを使用するか、適切なインターフェイスで API キーを管理します。

アカウントユーザー

セキュリティを最大限に高めるためにアカウントのユーザー資格情報を管理する方法は次のとおりです。

  1. Infobip Web インターフェイス内で、設定 → User & Teams に移動します。
    • 管理者ユーザーをアカウント マネージャー ロールのままにし、トラフィック ブロードキャストを許可するすべてのロールを削除します。他のユーザーの場合は、アカウント マネージャー ロールを削除し、トラフィック ブロードキャストのロールを割り当てます。
    • ユーザーのGSMとメールアドレスを確認します。
  2. 設定 → マイ アカウント に移動します。以下の一覧を参照し、各設定の構成方法の詳細については、「セキュリティ設定」トピックを参照してください。
    • 2要素認証はデフォルトで有効になっており、設定可能なオプションは「記憶」または「各ログイン時」です。2FA（二要素認証）API接続を妨げません。
    • パスワードの有効期間を設定します。
    • 最大ログイン試行回数を設定します。
    • ユーザーの非アクティブ日数を設定します。

交通セキュリティ

TLSのサポート

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

エントリ ポイント固有のユーザー

ユーザー資格情報は、Web インターフェイスまたは API を介して使用できます。API ユーザーと、Web インターフェイス接続を介して Infobip と対話するユーザーを混在させないことが重要です。

APIのユーザーを保持し(IP セーフリストからのみアクセス可能)、残りのユーザを Web インターフェイスに使用して、接続の問題を回避します。API ユーザーは、接続の問題を防ぐために、IP セーフリスト に属する URL を介してのみ API を使用できるようにする必要があります。

トラフィックブロードキャスト

SMPP 経由で API を使用する場合は、トラフィックをブロードキャストするための専用ユーザーを作成し、SSL 接続を介してそのクレデンシャルを使用してトラフィックをブロードキャストします。 HTTP 経由で API を使用する場合は、ユーザー資格情報を使用したトラフィックのブロードキャストは避けてください。代わりに APIキー を使用してください。

「 API キーの作成 (opens in a new tab) 」トピックで提案されているように、APIキーまたはトークン承認の種類を使用して、API接続のセキュリティを強化します。これは、ネットワークデータ転送の傍受のリスクを軽減するためです。

許可された IP アドレスの IP セーフリストを、IP または API キーの IP 範囲全体ごとに設定します。Infobip Web インターフェイスを使用してこれを行うには、ログインして 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 セーフリストを使用すると、人間のユーザーまたは API が Infobip プラットフォームにアクセスできる信頼できる IP アドレスまたは IP 範囲のリストを作成できます。

IP セーフリストを使用する場合は、次の規則とベスト プラクティスに留意してください。

IP セーフリストは、ユーザー レベルまたは APIキー レベルで設定できます。

  • ユーザーレベル

  • APIキー レベル

    • セーフリストで定義された IP アドレスは、トラフィックのブロードキャスト時に APIキー が使用されると認識されます。
    • APIキー の IP セーフリストは、Web インターフェイス (API キーの管理) を介して、または API を介して APIkey (opens in a new tab) を作成するときに設定できます。

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

  • API - 通常、静的 IP アドレスまたは会社/ISP 範囲を使用します。
  • Web Webインターフェイス - 動的ソース IP アドレス (自宅で作業しているユーザー、モバイル ネットワーク経由で接続しているユーザー、旅行中のユーザーなど) から発信される場合があります。
備考

HTTP APIキー と基本認証の IP セーフリストは補完的です (使用する認証方法に応じて異なる制限が適用されます)。

API 関連のセキュリティ制御

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

ネットワーク データ転送の傍受のリスクを軽減するには、次の操作を行います。

  • ネットワーク データ転送が傍受されるリスクが高いため、セキュリティで保護されていない HTTP と SMS over URL パラメーターの組み合わせは絶対に使用しないでください。
  • 暗号化されていない HTTP/SMPP 接続は使用せず、以下に切り替えてください。
    • SSL/TLS暗号化接続 - これは、セットアップが速く、フェールオーバーメカニズムがより堅牢であるため、推奨されるオプションです。
    • IPsec VPN 接続 - これは、可用性の問題が発生した場合に手動セットアップとより複雑なインシデント管理が必要なため、あまり好まれません。 これにより、プラットフォームと Infobip 間のデータ パスが暗号化されます。
  • メッセージの送信に GET メソッドを使用しない

パスワードの不正使用

パスワードの悪用のリスクを軽減するには、時間制約のある APIキー またはトークン認証の種類 を使用します。

API セッションは、最後に成功したトークンから 1 時間後に期限切れになり、このオプションはクライアントのアカウント レベルで変更できません。

一方、API キーはセッションレスであり、要求ごとに送信されます。APIキーごとに設定できる有効期間があり、その後、APIキーは無効/期限切れと見なされます。

統制が実施されない場合の潜在的なリスク

暗号化されていない HTTP/SMPP トラフィックを使用する場合のトラフィック傍受によるクレデンシャルの漏洩。これは、次の状況で発生する可能性があります。

  • 安全でない HTTP を基本認証 (権限付与ヘッダーのエンコードされた形式に含まれるユーザー名とパスワード) と組み合わせて使用する場合 - これは、ネットワーク、ISP とプロキシ サービス (使用されている場合)、および Infobip Web インターフェイスの間の任意のノードで発生した可能性があります。
  • クライアント ネットワークと Infobip プラットフォームの間で MITM メソッドを適用する場合。
  • あらゆる種類のストレージ(デジタルおよびアナログ)で安全でない(プレーンテキスト)形式で使用される場合。Infobip は、ユーザーのパスワードを一方向のハッシュ形式で保存し、アクセス権限は少数の信頼できる従業員のみに制限されます。アクセスは第三者に許可されません。
  • 交換/通信中(電子チャネル、電話、さらにはライブディスカッションを介して)安全でない(プレーンテキスト)形式で使用される場合。
  • 長期間パスワードを変更していない場合。

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

  • ユーザーごとに区別された、より長く複雑なパスワードを常に使用します。内部資格情報の保存と管理を強化して、将来のデータ漏洩の潜在的な原因を軽減します。
  • パブリック コード リポジトリにユーザー資格情報をハードコーディングすることは避けてください。
  • トークンをパスワードのように扱い、秘密にしてください。API を使用する場合は、トークンをプログラムにハードコーディングするのではなく、環境変数として使用します。

ログインページの真正性を検証してフィッシング攻撃を防ぐ

URL とサイトのコンテンツに細心の注意を払ってください。

  1. ファビコンを確認してください。Webサイトは、タブに必要なアイコンを配置できます。

  2. ドメイン名を見てください。ドメイン名は、正規の Infobip サイトにアクセスしていることを確認するのに役立ちます。

  3. ブラウザのアドレスバーでサイトのセキュリティステータスを確認してください。ほとんどのブラウザでは、安全な Webサイトには、WebサイトのURLの左側に緑色の南京錠のアイコンが表示されます。南京錠のアイコンをクリックすると、Webサイトの詳細(使用されている暗号化の種類など)を確認できます。例えば：

    • ドメイン名に複数のダッシュまたは記号が含まれています。
    • 実際のビジネスを模倣したドメイン名(例:「inf0bip」、「infoblp」、「infob1p」)。
    • 「.biz」や「.info」などのドメイン拡張子。これらのサイトは信頼できない傾向があります。
    • 「.com」サイトは、本質的に信頼性が低いわけではありませんが、入手するのが最も簡単なドメイン拡張機能であることにも注意してください。

  4. Webサイトの接続タイプを確認してください。Infobip WebインターフェイスのWebサイトにはhttpsタグがあり、より一般的なhttp指定を使用するサイトよりも安全であるため、信頼性が高くなります。これは、ほとんどの違法なサイトが、一般的なhttpsサイトが行うセキュリティ認証プロセスをわざわざ行わないためです。

  5. ファイルパスを見てください。Infobip Webインターフェイスには、アクセスするWebインターフェイスの部分に応じて、単純なファイルパスがあります。パスに関して疑問がある場合は、[Support](mailto:support@infobip.com]にお問い合わせください。

  6. URL を評価します。WebサイトのURLは、接続タイプ(「HTTP」または「HTTPS」)、アプリケーション(「ポータル」など)、ドメイン名(「infobip」など)、拡張子(「.com」)、およびファイルパス(「/dashboard」など)で構成されます。接続が安全であることを確認した場合でも、次の危険信号に注意してください。

    • ファビコン – Webサイトは、タブに必要なアイコンを配置できます。
    • ドメイン名 –これはURLの一部であり、探しているものを知っている限り、信頼できます。
    • ファイルパス/ディレクトリ–これはURLの一部であり、探しているものを知っている限り、信頼できます。
    • Webコンテンツ領域 – これは、Infobipの正規のWebサイトの非常に説得力のあるなりすましなど、攻撃者が望むものなら何でもかまいません。

  7. ウェブサイトで片言の英語を探してください。スペルが悪い(または欠落している)単語が多数あること、一般的に文法が悪い、またはぎこちない言い回しに気付いた場合は、サイトの信憑性を疑う必要があります。問題のサイトが詐欺でない限り技術的に合法であるとしても、言語の不正確さもその情報の正確性に疑問を投げかけ、それによって貧弱な情報源になります。

  8. 証明書の詳細の確認: ほとんどのブラウザでは、アドレスバーの南京錠アイコンをクリックして証明書を表示できます。

    Firefoxの場合:

    1. 南京錠のアイコンを選択します。
    2. 詳細情報 を選択します。
    3. [証明書の表示] を選択します。

    Safariの場合:

    1. 南京錠のアイコンを選択します。
    2. [証明書の表示] を選択します。

    Chromeの場合:

    1. 3ドットメニュー→その他のツール →開発者ツール を選択します。
    2. [セキュリティ] タブを選択し、[証明書の表示] を選択します。

    又は

    1. 証明書 →南京錠のアイコンを選択します。
    2. 証明書情報 を選択すると、CA が証明書を発行する前に検証したすべての情報が表示されます。

Infobip 証明書は次のようになります。

infobip security certificates

機密情報の共有

このセクションは、機密情報を安全に使用および保存する方法に関するクイックガイドです。

Sパスの使い方

S-PASS は、Infobipの従業員、クライアント、およびその他の第三者と機密情報を共有するためのInfobipアプリです。共有された情報は一度だけ読み取り可能 であり、その後S-PASSから完全に消去されることに注意してください。

送信者からトークンを受け取った場合は、秘密のメモを作成して受信者に送信する か、秘密のメモにアクセスして読む ことができます。いずれの場合も、任意のWebブラウザを使用してS-PASS (opens in a new tab)にアクセスする必要があります(Webブラウザによって表示が異なる場合があります)。

シークレットを保存する

  1. S-PASS (opens in a new tab)にアクセスします。秘密のメモを書く をクリックして秘密を誰かと共有するか、秘密のメモを読むためのトークンを受け取った場合は 秘密のメモを読む をクリックします。

    s-pass-sharing-confidential-information

  2. 送信したい秘密のメモを書いて貼り付けます。秘密のメモを保存する期間を選択します。読み取られるか、選択した保存時間を超えるまで保持されます。完了したら、ストア シークレット をクリックします。

備考

トークンを持っている人は誰でも、指定した期間に秘密のメモにアクセスできます。

これで秘密のメモが保存されました。**** トークンをコピーするか、直接リンクをコピーして、Secret stored! ポップアップからシークレットを共有します。

備考

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

シークレットを読み取る

直接アクセスリンク がある場合は、それをWebブラウザに貼り付けると、[シークレット]セクションの下に共有シークレットが表示されます。アクセストークン をお持ちの場合は、S-PASS (opens in a new tab)に移動し、秘密のメモを読む をクリックし、トークンを貼り付けて、トークンの送信 をクリックします。

備考

秘密のメモを読むと、システムから削除されます。

安全なファイル転送

Infobip Web インターフェイスを使用して、Infobip からレポートをエクスポートする方法を定義できます。この目的のために有効な方法は、FTP と SFTP です。

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

FTPプロトコルは、より安全な代替手段(SFTP、FTPS、SCP...)に完全に置き換えられているため、非常に信頼でき分離されたシステム**** 、または匿名FTPによるパブリックアクセスにのみ使用する必要があります。

SFTP (セキュア FTP) を使用することをお勧めします。クライアント側にSFTPサーバーを実装し、Infobip Webインターフェイスのエクスポート機能またはカスタマーケアに対してアクセスパラメータを提供するだけです。

安全な実装 プロセスは、通常、次のポインターに従います。

  1. 非標準ポート (22 以外) を指定します。
  2. 着信(送信者)IPアドレスをセーフリストに登録する。Infobip の場合、これらは193.105.74.4と62.140.31.104になります。
  3. 各 クライアント ユーザー専用の資格情報 (つまり、Infobip 専用の資格情報) を使用します。
  4. 長くて複雑なパスワード(12文字以上)を選択します。
  5. パスワードは定期的に変更してください(例:3か月ごと)。

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

安全でないバージョンのFTPを選択した場合、関連するセキュリティリスクを受け入れると同時に、Infobipはそのような使用に起因する可能性のある責任を放棄します。

Infobip リソースに対してセキュリティ テスト アクティビティを実行する権限付与

Infobipは、有名な第三者企業と連携し、以下を含むベストプラクティスの方法論を使用して、定期的な外部侵入テストを実施しています。

  • OSSTMM (オープンソース セキュリティ テスト手法マニュアル)
  • OWASP (Open Web Application Security Project) (オープン Web アプリケーション セキュリティ プロジェクト)
  • NIST ペネトレーションテストと監査の方法論(ターゲットシステムのセキュリティを評価するために設計された自動および手動の手法を含む)

Infobipは、契約したサービスの範囲に限定されたNDAに署名した上で、これらのテスト演習の詳細なレポートをクライアントおよびパートナーに提供します。当社のセキュリティチームは、レポートの内容や脆弱性管理プログラムのその他の側面に関する質問や議論に対応しています。

既存のレポートや文書を使用してサプライチェーンのセキュリティを検証することは、双方の運用上の負担とコストを削減しながら、適切な保証レベルを提供するため、有益です。

これらの議論が十分でない場合は、サービス利用規約および各サービス契約に規定されている規定に従って、環境の侵入テストまたは脆弱性スキャンを手配する場合があります。

クライアント/パートナーは、テスト結果をInfobipコーポレートセキュリティチームと共有することに同意する必要があります。Infobipの製品またはサービス内で特に重大かつ/または重大な問題が発見された場合、クライアントは遅滞なく調査結果をInfobipに報告することに同意するものとします。

重要

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

すべての外部セキュリティテストアクティビティはアナウンス する必要があり、リクエスト はInfobipの担当者(アカウント/セールスマネージャーまたはサポート)に送信する必要があります。

そのようなすべての要求は、テストを実施するための現在のクライアント/パートナーの許可に照らして評価されます。要求が承認された場合、要求当事者は、Infobip Corporate Security 部門から提供される 外部侵入テスト文書 に記載されている、契約に関する定義された一連の要件に準拠する必要があります。

NDAの規定に従い、お客様は、**** 発見された脆弱性の機密性を保護する責任を負います。そのような情報は、いかなる形式であっても、Infobip Corporate Security部門の事前の承認なしに、第三者に開示または共有してはなりません。

クライアントがこの機密保持条項に違反した場合、Infobipは契約条項に基づいてクライアントに責任を負わせ、潜在的な払い戻し請求は、これらの不正な活動から生じる損害の最大額を考慮に入れます。

実施されたペネトレーションテストでInfobipシステムの脆弱性が発見された場合、これらの調査結果はInfobipコーポレートセキュリティ部門によってトリアージされます。修正が必要とマークされた場合、特定された脆弱性の修復の証拠は、専任のアプリケーションセキュリティ専門家およびその他の関連するセキュリティ専門家によってまとめられた内部プロビジョニングレポートの形式で、要求する第三者に提供されます。

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

内部資格情報の保存と管理を強化して、Infobip プラットフォームへの不正アクセスとトラフィック コストにつながる可能性のある将来の内部データ漏洩の潜在的なリスクを軽減します。

パスワードを安全に保管するには、商用グレードのパスワード管理ツールの使用を検討してください。

資格情報の保存 (操作方法と使用方法)

Infobip API を使用している場合は、パスワード、トークン、シークレットなどの機密データを処理する必要があります。これは、特にサービス操作を実行するために機密データをあるサービスから別のサービスに送信する必要がある場合、非常に困難な場合があります。

機密データを保存する必要性は正当なユースケースであり、設計段階で何度も発生する可能性があります。リソースを共有して操作を開始する安全な方法に頼ることができない場合は、階層で設定された追加のセキュリティメカニズムを設定し、多層防御を強化する必要があります。

承認がハードコーディングされているシナリオ コードの例を次に示します。

java
 
    public class InfobipApp {
     
        public static void main(String... args) {
            OkHttpClient client = new OkHttpClient().newBuilder().build();
            MediaType mediaType = MediaType.parse("application/json");
            RequestBody body = RequestBody.create(mediaType, "{\"messages\":[{\"from\":\"InfoSMS\",\"destinations\":[{\"to\":\"41793026727\"}],\"text\":\"This is a sample message\"}]}");
            Request request = new Request.Builder()
                .url("https://api.infobip.com/sms/2/text/advanced")
                .method("POST", body)
                // The sensitive secret is hardcoded in code below
                .addHeader("Authorization", "App 003026bbc133714df1834b8638bb496e-8f4b3d9a-e931-478d-a994-28a725159ab9")
                .addHeader("Content-Type", "application/json")
                .addHeader("Accept", "application/json")
                .build();
            Response response = client.newCall(request).execute();
            System.out.printf("%s: %d", number, response.code());
        }
    }

これは、私たちが防ぎたいシナリオです。

これらのセキュリティメカニズムと、機密データを保護する方法をいくつか見てみましょう。

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

ハードウェアセキュリティモジュールは、通常、改ざん防止FIPS 140-2レベル3デバイスとして正式に認定された特別な物理デバイスであり、機密資料を保存および保護し、暗号化操作を安全に実行するように設計されています。HSM の背後にある考え方は、アプリケーションがデプロイされているコンピューターではなく、より安全な環境でデータを格納したり、操作を実行したりすることです。HSM にはさまざまなプロバイダーがあり、その使用方法と運用方法はプロバイダーのドキュメントの範囲内にあります。これは、機密データの処理に使用できる最適なアプローチです。

機密データは絶対に保存しないでください

機密データを保存する代わりに、デプロイ時にアプリケーションに含めます。起動時にアプリケーションがシークレットを要求するようにします。これは、パスワードがメモリにしか含まれていないためHSMを使用できない場合にできる最善のことです。

これに関連するリスクは他にもあります。たとえば、アプリケーションがサービスとしてデプロイされている場合に、メモリから直接パスワード/キーを取得したり、サーバーの再起動などの可用性のリスクが発生したりします。この方法は、他のどの方法よりもはるかに安全です。他のすべての方法には、メモリから機密データを取得することに関連する同じリスクがあります。

これを単純なSpring Bootアプリケーションに組み込む方法の例を次に示します。

java
 
    @SpringBootApplication
    public class InfobipApp implements CommandLineRunner {
    private NumberRepository numberRepository;private SensitiveData sensitiveData;
    @Autowiredpublic App(NumberRepository numberRepository, SensitiveData sensitiveData) {	this.numberRepository = numberRepository;	this.sensitiveData = sensitiveData;}
    @Overridepublic void run(String... args) throws Exception {	for (String number : numbersRepository.findAll()) {
            	OkHttpClient client = new OkHttpClient().newBuilder().build();
            	MediaType mediaType = MediaType.parse("application/json");
            	RequestBody body = RequestBody.create(mediaType, String.format("{\"messages\":[{\"from\":\"InfoSMS\",\"destinations\":[{\"to\":\"%s\"}],\"text\":\"This is a sample message\"}]}", number));
            	Request request = new Request.Builder()
                	.url("https://api.infobip.com/sms/2/text/advanced")
                	.method("POST", body)// Authorization is fetched from bean and sensitive data is not stored in code
                	.addHeader("Authorization", data.getAuthorization())
                	.addHeader("Content-Type", "application/json")
               		.addHeader("Accept", "application/json")
                	.build();
            	Response response = client.newCall(request).execute();System.out.printf("%s: %d", number, response.code());	}
        }
    
        @Bean
        public SensitiveData getSensitiveData() {Console console = System.console();SensitiveData data = new SensitiveData();data.setAuthorization(console.readPassword("Input Infobip API authorization: "));return data;
        }
    
        public static void main(String... args) throws IOException {SpringApplication.run(InfobipApp.class, args);}
    }

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

機密データを本当に保存する必要があるイベントでは、追加の防御層を設定します。

ここにはいくつかのオプションがあります。

  1. 検証済みの暗号化ストア(キーストアなど)にシークレットを保存し、アプリケーションの起動時にそれらのシークレットをロードします。
  2. シークレットを暗号化し、暗号化キーを安全に格納し、サービス上の特定のユーザーのみに制限されるようにします。
  3. 環境変数にシークレットを格納し、コードで値をフェッチします。
  4. 認証後にアプリケーションにシークレットを提供する別のプロセスまたはサービスを使用します。

以下は、環境変数からシークレットを取得する方法のコード例です。

java
 
    @SpringBootApplication
    public class InfobipApp implements CommandLineRunner {
    private NumberRepository numberRepository;
    @Autowiredpublic App(NumberRepository numberRepository) {this.numberRepository = numberRepository;}
    @Overridepublic void run(String... args) throws Exception {for (String number : numbersRepository.findAll()) {
            	OkHttpClient client = new OkHttpClient().newBuilder().build();
            	MediaType mediaType = MediaType.parse("application/json");
            	RequestBody body = RequestBody.create(mediaType, String.format("{\"messages\":[{\"from\":\"InfoSMS\",\"destinations\":[{\"to\":\"%s\"}],\"text\":\"This is a sample message\"}]}", number));
            	Request request = new Request.Builder()
                	.url("https://api.infobip.com/sms/2/text/advanced")
                	.method("POST", body)// Authorization is fetched from environment variable and sensitive data is not stored in code
                	.addHeader("Authorization", System.getenv("INFOBIP_API_AUTHORIZATION"))
                	.addHeader("Content-Type", "application/json")
               		.addHeader("Accept", "application/json")
                	.build();
            	Response response = client.newCall(request).execute();System.out.printf("%s: %d", number, response.code());	}
        }
    
        public static void main(String... args) throws IOException {SpringApplication.run(InfobipApp.class, args);}
    }

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

インターネット上でのサイバー攻撃の大幅な増加に伴い、Webアプリケーションはさまざまな方法で攻撃されています。これらの攻撃を効果的に防御するために、詐欺事件で利用される最も一般的なWebアプリケーションの問題の観点から実装できるWebアプリケーションセキュリティガイドラインを提供しています。

不正事件で利用されるWebアプリケーションの問題

  1. 詐欺事件で利用されたWebアプリケーションの問題

    SMSメッセージの頻度と量を特定の数に制限して、ユーザーがサービスやプラットフォームを悪用できないようにします。このアプローチを使用すると、エンド ユーザーへの潜在的なスパムを回避し、エンド ユーザーによってリソースが使い果たされる可能性がなくなります。レート制限は、ユーザーアカウントレベルで実装する必要があります。

  2. HTTPヘッダーとCookieのセキュリティメカニズムの欠如

    HTTPヘッダーには、Webアプリケーションに追加のセキュリティレイヤーを提供できる一連のセキュリティメカニズムが含まれている必要があります。アプリケーションCookieには、少なくとも「Secure」および「HttpOnly」ディレクティブが必要です。追加のオプションは、クロスオリジン情報漏洩のリスクを軽減する SameSite を含めることです。 Cookieを保護するだけでなく、アプリケーションはX-Frame-Optionsを使用してクリックジャッキング攻撃を回避し、X-XSS-Protectionを使用してXSS攻撃を軽減し、Strict-Transport-Securityを使用してHTTPSのみを使用するようにブラウザに指示する必要があります。

  3. 一部の API エンドポイントで認証またはレート制限がありません

    一部のエンドポイントはデバッグモードまたはテストモードになり、テスト目的で使用されるエンドポイントでは認証またはレート制限が無効になる可能性があるため、すべてのAPIエンドポイントを適切に管理することが重要です。これは、複数のデプロイ (運用、ステージング、内部、および開発) で下位互換性を維持する状況で一般的です。

  4. 安全でない直接オブジェクト参照

    アプリケーションは、データベースから特定のオブジェクトにアクセスしようとしたユーザーがそのオブジェクトへの適切なアクセス権を持っているかどうかを確認する必要があります。IDOR は通常、ユーザーが URL 内のオブジェクトの ID を 10 から 20 に変更するなどして入力を変更したときに発生します。ユーザーは、別のユーザーに関連付けられているオブジェクトにアクセスできます。アプリケーションでは、ID などの実際の識別子の公開を防ぎ、シーケンシャル ID は簡単に推測できるため、代わりにハッシュを使用する必要があります。

  5. CAPTCHAメカニズムがない、または安全でない

    reCAPTCHAまたはhCAPTCHAを使用してボットに対処します。ボットと人間の相互作用の両方を使用して解決される自動化されたCAPTCHAソルバーの存在に注意してください。グラフィックパズルの解答やコンテキスト固有の質問など、従来とは異なるCAPTCHA手法の使用を検討してください。

  6. CSRF対策トークンがありません

    すべての機密性の高いHTTPリクエスト内でアンチCSRFトークンを使用することをお勧めします。CSRFトークンは、セッションごとに生成されるCSRFトークンとは対照的に、エクスプロイトの時間範囲が短いため、HTTPリクエストごとに生成する必要があります。

  7. 機密データを API に送信するための GET パラメーターの使用

    URL は HTTP プロキシ、ブラウザーの履歴、または Web サーバーのログにキャッシュされる可能性があるため、機密データや API キーの送信に GET パラメーターを使用することは避けてください。機密データを API に送信するには、HTTP POST メソッドを使用します。

  8. Web アプリケーションは、インジェクション ペイロードなどの危険な入力をフィルター処理およびサニタイズしません

    Web アプリケーションの形式で使用できるデータの種類を定義します。入力を検証してエスケープします。たとえば、ユーザー名フィールドでは英数字の文字列のみを受け入れるため、特殊文字を受け入れる必要はなく、電話番号フィールドでは数字のみを使用する必要があります。 HTMLフォームから直接ユーザー入力を使用する代わりに、SQLインジェクションのリスクを最小限に抑えるために、基礎となるデータベースと対話するときに、パラメータ化されたクエリでストアドプロシージャまたはプリペアドステートメントを使用します。XSS は、日付や yes/no 選択などの入力選択がない各フォームで検証と入力サニタイズを使用して対処し、常により小さい (<) やより大きい (>) などの特殊文字をエンコードする必要があります。

  9. HTTP 経由の安全でない接続

    HTTPを使用する代わりに、HTTPトラフィックの暗号化を提供し、トラフィックの傍受から保護するため、HTTPSに切り替えます。プレーンなHTTPプロトコルを使用すると、ユーザーが公共のWi-Fiホットスポットまたは安全でないネットワークに接続されている場合、APIキーまたはユーザー資格情報が盗聴される可能性があります。SSL 2.0/3.0 の使用を避け、TLS 1.0 を無効にし、TLS 1.2 と TLS 1.3 を使用します。ヌル暗号と匿名暗号を無効にします。

  10. 不十分なログ記録と監視

    Web アプリケーションは、保存時と転送時に適切なレベルの整合性で十分な数のログを生成できる必要があります。また、アプリケーション ログは、プレーンテキストの資格情報やメッセージの内容などの機密情報からサニタイズする必要があります。これは特に、認証や、パスワード/APIキーの登録や変更、アクセスの拒否、入力検証エラーなどの機密性の高いアクションに当てはまります。ログ記録と監視は、将来のフォレンジックとユーザーのアクションの調査の要件です。

Logo

ご不明点は

サポートまでお問い合わせ

ください

© NTTCom Online Marketing Solutions Corporation