Security

セキュリティ

通信の安全性

SSL通信による通信データの暗号化

インターネットを使ったサービスの中には、通信途中で第三者に盗み見られたり改ざんされる可能性があるものがあります。ABCD PartnersのWebサービスは、通信のすべてをSSLを用いてデータを暗号化してあるので、第三者が内容を確認することができません。

サーバー環境

1.高度なセキュリティと信頼性を持つデータセンター

ABCD PartnersのWebサービスは、Amazon Web Services（以降、AWS）のデータセンター（東京リージョン）を利用しています。 AWSはAmazon社が提供するデータセンターサービスで、同社が長年の大規模データセンターを運用した経験をもとに設計・構築・運用されています。 非常に高い信頼性を持つ認証と認定を受けており、多数の豊富な実績があります。

2.高度なセキュリティと信頼性を持つデータセンター

AWSのサーバーは独立した電源、空調、ネットワーク環境を持つ、異なるデータセンターにまたがって配備されています。 例え特定のデータセンターでハードウェアの物理的な障害やネットワーク障害が発生したとしても、待機している他のデータセンターのサーバーへと自動で切り替わり、運用を継続することができます。

3.安心のバックアップ体制

データベースのデータは常にバックアップされており、万が一、弊社がデータを消失させる事故を発生させたとしても、過去の状態にもデータを復元することができる体制をとっております。さらに、通常の運用サーバーとは全く異なる系統の専用サーバーへと、バックアップデータを保管しています。バックアップデータの保管にはAmazon S3を使用しており、複数の施設にまたがって多重に格納されることで、付与された1年に対して99.999999999%という極めて高い耐久性を持つよう設計されています。

その他Amazon Web Servicesのセキュリティ詳細についてはAWSセキュリティセンターをご覧ください。

セキュリティ実装 チェックリスト

1.SQLインジェクション

根本的解決

対応済SQL文の組み立ては全てプレースホルダで実装する。
対応済SQL文の構成を文字列連結により行う場合は、アプリケーションの変数をSQL文のリテラルとして正しく構成する。
対応済ウェブアプリケーションに渡されるパラメータにSQL文を直接指定しない。

保険的解決

対応済エラーメッセージをそのままブラウザに表示しない。
対応不要データベースアカウントに適切な権限を与える。

2.OSコマンド・インジェクション

根本的解決

対応済シェルを起動できる言語機能の利用を避ける。

保険的解決

対応済シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。

3.パス名パラメータの未チェック／ディレクトリ・トラバーサル

根本的解決

対応済外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。
対応済ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする。

保険的解決

対応済ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理する。
未対応ファイル名のチェックを行う。

4.セッション管理の不備

根本的解決

対応済セッションIDを推測が困難なものにする。
対応済セッションIDをURLパラメータに格納しない。
対応済HTTPS通信で利用するCookieにはsecure属性を加える。
対応済ログイン成功後に、新しくセッションを開始する。
対応済ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認する。

保険的解決

未対応セッションIDを固定値にしない。
未対応セッションIDをCookieにセットする場合、有効期限の設定に注意する。

5.クロスサイト・スクリプティング

HTMLテキストの入力を許可しない場合の対策（根本的解決）

対応済外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。
対応済ウェブページに出力する全ての要素に対してエスケープ処理を施す。
対応済URLを出力するときは「http://」や 「https://」で始まるURLのみを許可する。
対応済要素の内容を動的に生成しない。
対応済スタイルシートを任意のサイトから取り込めるようにしない。

保険的解決

対応済入力値の内容チェックを行う。

HTMLテキストの入力を許可する場合の対策（根本的解決）

対応済入力されたHTMLテキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する。

保険的解決

対応済入力されたHTMLテキストから、スクリプトに該当する文字列を排除する。

全てのウェブアプリケーションに共通の対策（根本的解決）

対応済HTTPレスポンスヘッダのContent-Typeフィールドに文字コード（charset）の指定を行う。

保険的解決

対応済Cookie情報の漏えい対策として、発行するCookieにHttpOnly属性を加え、TRACEメソッドを無効化する。

6.CSRF （クロスサイト・リクエスト・フォージェリ）

根本的解決

未対応処理を実行するページを POST メソッドでアクセスするようにし、その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。
未対応処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。
対応済Refererが正しいリンク元かを確認し、正しい場合のみ処理を実行する。

保険的解決

未対応重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する。

7.HTTPヘッダ・インジェクション

根本的解決

対応不要ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用する。
対応不要改行コードを適切に処理するヘッダ出力用APIを利用できない場合は、改行を許可しないよう、開発者自身で適切な処理を実装する。

保険的解決

対応不要外部からの入力の全てについて、改行コードを削除する。

8.メールヘッダ・インジェクション

根本的解決

対応済メールヘッダを固定値にして、外部からの入力はすべてメール本文に出力する。
対応済ウェブアプリケーションの実行環境や言語に用意されているメール送信用APIを使用する。
対応済HTMLで宛先を指定しない

保険的解決

未対応外部からの入力の全てについて、改行コードを削除する。

9.アクセス制御や認可制御の欠落

根本的解決

対応済アクセス制御機能による防御措置が必要とされるウェブサイトには、パスワード等の秘密情報の入力を必要とする認証機能を設ける。

保険的解決

対応済認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする。