旅行会社のデータ・決済・GDSを守るセキュリティ

リスクにさらされる場面

予約1件で確認したい5つのリスクポイント

1件の予約を業務の流れに沿って追ってみましょう

• 新規の旅行者や企業が、相手の身元を確認できないうちに大量の航空券を依頼してくる。
• メールのリンク先が、GDS、決済事業者、仕入先ポータルに見せかけたログインページになっている。
• パスポートのコピー、決済情報、最新の日程表が、受信トレイ、スプレッドシート、共有フォルダに残っている。
• 支店、個人契約の代理人、ベンダー、退職者が、まだ予約システムにアクセスできる。
• ランサムウェアの被害により、旅行者対応に必要な日程表や連絡先のデータが使えなくなる。

確認事項

データの種類ごとに確認したい質問

• どのような情報を収集していますか？
• なぜその情報が必要ですか？
• どこに保管していますか？
• 誰が閲覧、変更、ダウンロード、共有できますか？
• どの仕入先やプラットフォームに渡りますか？
• いつ削除すべきですか？

システム

日常的に使うシステムも対象に含める

• メール、CRM、GDS
• ミッドオフィスのプラットフォームと会計ソフト
• 決済プロバイダー、共有ドライブ、スプレッドシート
• 旅程作成ソフト、アプリ、仕入先のポータル

多要素認証を必須にする

メール、CRM、クラウドストレージ、予約システム、決済ツール、管理者アカウントのほか、対応しているすべてのプラットフォームで多要素認証を有効にしてください。盗まれたパスワードだけで業務システムに入れる状態は避けるべきです。

提供元が対応している場合は、フィッシングに強い認証方式を使用してください。対応していない場合は、SMSのみに頼らず、認証アプリまたはセキュリティキーを使用してください。

一人ひとりに個別のアカウントを発行する

社内で共通のアカウントのログイン情報を共有しないでください。個別のアカウントであれば、誰がどの記録にアクセスしたかを確認でき、担当が変わったときに権限を変更し、従業員や委託先が退職・契約終了したときにアクセスを削除できます。

権限は、業務に必要な範囲にとどめてください。たとえば、営業担当は旅行者の情報を閲覧する必要があり、管理者は設定を管理する必要があるかもしれません。

パスワード管理ツールを使う

パスワード管理ツールを使えば、重複のないパスワードを作成でき、メールやスプレッドシートではなく、アクセス管理された保管庫でログイン情報を共有できます。メールアカウントと、仕入先や予約プラットフォームのアカウントで、同じパスワードを使い回さないでください。

GDS

GDSと発券のアクセスを守る

• GDSや連携サービスが対応している場合は、必ず多要素認証を有効にしてください。
• 新規の法人顧客は、メールの依頼内容だけに頼らず、自社で調べた連絡先を通じて確認してください。
• 発券状況をこまめに確認してください。特に、出発日が近いもの、通常と異なる経路、片道予約、新規の旅行者プロフィール、取扱件数の急な増加に注意が必要です。
• 従業員、委託先、支店、ベンダーとの関係が終了したときは、アクセス権限を取り消してください。
• 不審なページにログイン情報を入力してしまった場合は、直ちにパスワードを変更し、MFAを再登録し、端末をスキャンして、GDSとARCに連絡してください。

一度立ち止まる

次のような依頼を受けたときは、いったん手を止めるよう、スタッフに徹底してください。

• パスワード、ワンタイムコード、支払い情報の要求
• 仕入先の振込先情報の変更
• 緊急の送金または返金
• パスポートのコピーや顧客リストの提出
• 予約システムや決済システムへのサインインを促すリンク

提供事業者

ホスト型の決済フォームまたはトークン化を利用する

提供事業者がカードデータを保管する場合でも、貴社で対応が必要な事項と、適用されるPCI DSSの要件を確認してください。PCI Security Standards Councilによると、PCI DSSは、決済アカウントデータを保管、処理、送信する事業者のほか、そのセキュリティに影響を与え得るシステムにも適用されます。

スタッフ向けルール

支払い依頼への対応について、明確なルールを定める

顧客がどの決済ページを使うべきかを把握し、スタッフが正規の支払い連絡を見分けられるようにします。手順上可能な限り、カード情報は日程表の作成業務に持ち込まないでください。

計画

インシデント対応計画に盛り込む内容

• 対応を指揮する人と、緊急の判断を下せる人。
• 不審なメール、端末の紛失、アカウントの侵害をスタッフが報告する方法。
• 連絡すべきテクノロジー提供会社、保険会社、法律顧問、関係当局。
• 証拠を消さずに、端末やアカウントを切り離す方法。
• 予約システムや連絡手段が使えなくなった場合に、旅行者への対応を続ける方法。
• 影響を受けたデータを把握し、適用される規則に沿ってお客様に連絡する方法。
• システムを復旧し、インシデント後に原因を検証する方法。

Amazon Web Servicesでホスティング

プラットフォームはAmazon Web Services上で稼働しています。欧州のお客様のデータはドイツのフランクフルトでホスティングされ、アップロードされたファイルは英国のロンドンに保存されます。それ以外のお客様のデータは、米国のノースバージニアでホスティングされます。

通信時と保存時の暗号化

mTripによると、プラットフォームとAPIの通信にはTLS 1.2以上を使用しています。データベース、ファイルストレージ、バックアップは保存時にAES-256で暗号化しています。さらにアプリケーション側で、メールアドレス、電話番号、生年月日、予約番号といった旅行者の機微な項目も暗号化しています。

毎日のバックアップと年1回のテスト

プラットフォームでは、暗号化したバックアップを毎日取得し、7日間のポイントインタイムリカバリに対応しています。mTripはバックアップを別のAWSリージョンにも複製し、削除から保護したうえで、少なくとも年1回は復元テストを行っています。

アクセス制御と第三者によるテスト

mTripは、アクセス制御、多要素認証、管理者操作のログ記録、脅威の継続的な検知に加え、プラットフォームとモバイルアプリを対象とした第三者によるテストを少なくとも年1回実施していると説明しています。

セキュリティ審査

旅行業向けテクノロジー提供会社に必ず確認したい質問

データのホスティング場所、アクセス制御の方法、バックアップのテスト方法、インシデントの報告方法、契約終了後のデータの扱いを確認してください。

mTripのセキュリティへの取り組みを確認する

アクションプラン

最初のプロジェクトで取り組む6つの対策

• 予約と日程表の作成業務で扱うデータを洗い出します。
• 重要なアカウントすべてで多要素認証を有効にします。
• 不要になったユーザー、共有ログイン、使っていない連携を削除します。
• クレジットカード情報の全桁を、メール、文書、スプレッドシートに残さないようにします。
• 復元テストを行い、バックアップが機能することを確認します。
• インシデント対応計画を作成し、チームで訓練します。