FAQ/セキュリティについて(全体像）
概要
インターネット上に公開されているサーバは公開直後から間断なく自動化された攻撃を受けておりセキュリティ対策が必須です。
本システムが実施しているセキュリティ対策について説明します。
説明
アプリケーションレベルの対策
- 全ページHTTPS対応・・・全ての画面で暗号化通信を利用しています。
- SQLインジェクション対策・・・外部から入力された情報を利用してSQLを組みたてる場合は必ず「クエリパラメタ」を利用しています。
- CSRF対策・・・POSTメソッドではCSRFトークンを利用しています
- パスワードの不可逆暗号化・・・パスワードは不可逆暗号化して保存しています。ログにも出力されないことを確認しています。
- reCAPTHA対応・・・botによる問い合わせフォームからのフィッシング詐欺の投稿をブロックします。
- クレジットカード情報非通過・非保持・・・クレジットカード番号は本システムのサーバには一瞬たりとも保持されません。
- 管理サイト
- 権限管理/アクセス制御・・・事業者、モール運営者、システム管理者ごとにアクセスできる情報を制限しています。
- ユーザアカウントの個人別発行・・・アカウントを個人ごとに発行することで「誰が」操作したか特定できます。不正操作の抑止効果が期待されます。
- 操作の記録・照会・・・「誰が」「いつ」「どんな操作を行ったか」「どんなデータにアクセスしたか」を記録しています。(モール運営者が照会できます)
インフラでの対策
侵入の防止・検知
- ポート制限・・・WebサーバはSSH、HTTP、HTTPS以外のリクエストは拒否します。(HTTPはHTTPS強制的にリダイレクト)
- SSH鍵認証・・・サーバへのログインはSSH鍵が必須です。パスワード認証やrootログインは不可。アクセス元IPアドレスも制限しています｡
- ログイン通知・・・サーバへのSSHログインがあった場合、事前に登録したメールアドレスに通知します。
- IPアドレス制限・・・攻撃してくる端末のIPアドレスを記録。IPアドレス制限を追加してアクセスを拒否します。国外からのアクセス拒否もできます。firewall/fail2banなど
- セキュリティパッチ自動適用・・・yum-cronによりセキュリティ自動的に適用します。
- サービス死活監視・・・数分ごとにサービスの死活監視を実行します。無応答や異常応答時はシステム管理者に即時通知します。
- GuardDuty導入・・・GuardDuty(脅威検出サービス)を導入して危険度の高い攻撃の発生を迅速に検知します。
改ざん検知
- 改ざん検知ソフト(AIDE等)を活用して常に改ざん有無をチェックしています。
DDoS攻撃対策
- 基本対応・・・一定時間内に既定のリクエスト回数を超えたIPアドレスを自動的にban(アクセス拒否)します。fail2ban, firewalldなど
- AWS Sheild・・・インフラ(AWS)から基本的な防御機能が提供されています。詳細はAWS Sheild(外部サイト)を参照してください。
- [オプション]より大規模な攻撃への備えや専門家による高度な対策の実施も可能です。AWS Shield Advanceを参照。月額3000ドル～
- WAF対応・・・負荷分散装置(ALB)に付属するWAF(Webアプリケーションファイルウォール)の利用
- CloudWatchによる異常検知
- Requests HTTP(S)リクエスト数
- TotalErrorRate 全リクエスト中の HTTP ステータスコードが 4xx または5xx である割合
障害復旧
- アプリケーションの自動再起動・・・予期せぬサーバ再起動時に自動的にアプリケーションを起動します。あわせて管理者に通知します。
- データバックアップ
- 毎日バックアップを実施します。(データベース、静的ファイル、ログ、サーバ設定ファイルなど)
- バックアップデータは99.999999999%の可用性を保証されているクラウドストレージ(AWS S3)に格納します。
- S3上のデータは定期的に自社インフラに同期させます
- ソースコード
- gitによりバージョン管理されています。
- 最新版および履歴は物理的に異なる場所(クラウドおよび自社)に保存しています。
サポート体制
- サーバ障害・セキュリティインシデントについては365日24時間即時対応します。
よくある質問
-
CSRF対策：CSRFトークンとは、ワンタイムトークンのような認識でよいでしょうか。
-
はい、おっしゃるとおりです。
以下は問い合わせフォーム例ですが「推測不可能な乱数」を表示の都度発行します。送信された場合に、サーバ側でチェックして発行した値と一致していなければエラーとなります。「予約処理」などデータ更新を伴う操作に対して設定してあります。
- お客様にreCAPTHAが表示されるのはお問い合わせフォームからの送信時の想定でよろしいでしょうか。
-
はい。そのとおりです。
- 「クレジットカード情報非通過・非保持」とはカード会社や決済代行会社のシステム上で決済することで合っていますでしょうか。
-
はい、この内容(システム外で決済処理を行う)も含まれます。
より具体的には「カード番号が一瞬たりとも本システムのサーバを経由しない」ことを意味します。
たとえば、データベースに保存しないでも、サーバにカード番号を送信している場合は「通過している(非通過に対応できてない)」となります。
詳しくは以下をご参考にして頂ければと思います。
- 操作の記録・照会：具体的にはどのように管理者は閲覧できるのでしょうか。CSVにログで出力するようなイメージでしょうか。また、照会が必要となるのは何らかのトラブル発生時と思っておいてよいのでしょうか。
-
「管理サイト > ユーティリティ > 操作履歴照会」からいつでも照会できます。詳しくは「操作履歴の記録/照会/ダウンロード」を参照してください。
- サーバーにログインするのは、システム開発者である御社と、モール運営者である弊社のみでしょうか。
-
いいえ。サーバ(コンピュータシステム)へのログインや、各種設定の照会・更新は、弊社だけとなります。管理サイト(予約や受注、顧客の照会といった管理機能)にはモール運営者や参画事業者がアクセスできます。
- (データセンター障害等に伴い)バックアップデータから何らかのデータを復元する際は、御社に依頼することでよろしいでしょうか。モール運営者や参画事業者側に瑕疵がなければ費用負担は発生しないでしょうか？
-
はい。弊社にご依頼ください。
ただ、バックアップに含まれないデータ(例えば最後のバックアップ後に発生した予約・受注や残在庫数)の復旧は手作業となり、事業者やお客様への連絡も必要となることもあるかと思いますので、その場合、適宜、ご協力いただけるようお願いいたします。
( たとえば、データの取りまとめ(予約受付メールを見てExcelにまとめていただく)や各事業者様への在庫確認依頼などです。)追加の費用負担は発生しません。