この文書は、esa LLC(以降、当社と呼ぶ)の運営する、esa.ioが取り扱う情報セキュリティに関してのポリシーである。
esa.ioの利用者が、安心してサービスを利用できるようにするため、当社の情報セキュリティに対するポリシーを示し、社員全員がこれを尊守する。
セキュリティポリシーが適用される人は当社のコーポレートサイト team.esa.ioに記載される社員全員とする。
適用される情報資産は、後述の当社の取り扱う情報資産についてへ記載する。
本セキュリティポリシーは当社の他の規定よりも優先される。
本セキュリティポリシーを定め、運用と監視を行う。
本セキュリティポリシーに則り情報資産を取り扱う。
月に一度、情報資産取扱の責任者と経営メンバーにおいて以下の項目のレビューを行い、必要があれば改定を行う。
具体的には社内のslack reminderを用いて、見直し実施をお知らせし、見直しを行う。
esaの該当記事に変更箇所のdiffを貼り、それに対して社員全員が「LGTM」とコメントすることで承認したものとする。
セキュリティーポリシーの制定と改定、組織内の尊守に責任を持つ。
情報資産を取扱い、運営サポートを行うものを以下に定める。
各チームの/team
からアクセス出来るチーム情報と、ユーザー情報、投稿情報の3つに情報資産を分類する。
チーム情報、ユーザー情報については、運営サポート業務に限り、運営サポート業務を行うものへ管理者用ページのアクセス許可を与える。投稿情報に関しては、後述するDB管理者以外に一切のアクセス権限は与えない。またDB管理者においても特別の事情がない限り一切の投稿情報へのアクセスは行わないものとする。
運営サポート業務を行うものが、その業務範囲内において、以下の情報を閲覧できるページを指す。
管理者用ページは正しいアクセス権限持ったユーザーのみがアクセス出来ることを自動テストにて担保する。
PAY.JPと紐付けるtoken情報のみ保持する。PAY.JPへのアクセスキーなどは、暗号化して保存している。
暗号化とは、環境変数の暗号化を指す。
情報資産の取扱範囲について、全社員にそれぞれの役割におけるアクセス権限の範囲と責任について合意書を締結するものとする。
セキュリティポリシーに関する意識向上のための適切な教育・訓練として、以下の教育動画を定期的(約半年に一度を目安とする)に閲覧することを義務付ける。
違反のレベルに応じて、適切に対処する。
会社/情報セキュリティ規定/入社時・退職時のマニュアル(社内文書)に記載する。
業務において発見あるいは疑いをもった情報システムの脆弱性や情報セキュリティインシデント(サービス停止、情報の漏えい・改ざん・破壊・紛失、ウイルス感染等)について、従業員はすみやかに当社のslackにて報告を行う。後日、docs.esa.ioにまとめる。
業務委託先事業者、顧問などについても社員と同等のセキュリティポリシーの尊守を契約書に盛り込み、義務付ける。
サービスの提供および継続上重要な記録として以下の監査ログを取得している。
AWSのRDSを利用する。
運用に必要なデータベースの設定・管理などの作業を行う権限を持つ者を指す。
主な情報は、サービス運用ポリシー内のインフラ情報を参照のこと。
運用に必要なインフラの設定・管理などの作業を行う権限を持つ者を指す。
AWSのIAMを用いて、インフラ管理者が行う。
Webサーバ、OSデフォルトの名称やバージョン情報をエラー情報などに表示しない。
Elastic Load Balancing で事前定義された SSL のセキュリティポリシー の TLS-1-2-2017-01 を利用。
HTTPへのアクセスはHTTPSへリダイレクトしている。
Googleアカウントでのログインのみ許可している。
名前とパスワードのガイドライン
https://support.google.com/a/answer/33386?hl=ja
に準拠。
サービスの提供に用いるアプリケーション等の新規開発時や改修時において、定期的な実施時と同等またはそれ以上の水準で脆弱性診断を行い、その結果に基づいて対策を行っている。
brakeman
A static analysis security vulnerability scanner for Ruby on Rails applications
を用いてソースコードの静的解析により対策を施している。
アプリケーションのソースコードレビューは、開発者とは別の第3者により実施され、セキュリティの観点を含んで確認を行う。
具体的にはGitHub上のPull Requestを用いて行う。
エラー発生時の表示メッセージに、問い合わせなどに必要な情報のみを記載し、内部構造が推測できるような不必要な情報を表示しない。
また、その際のサーバー内のログ出力において、開発・監視に直接関わることの少ない、ユーザーのプライバシーに関わるような情報を出さない。
直ちに、各チームのownerへメールにて報告する。必要な場合は全サービスをメンテナンスモードへ移行後、直ちに各チームのownerへメールにて報告する。
この文書は、esa LLC(以降、当社と呼ぶ)の運営する、[esa.io](https://esa.io)が取り扱う情報セキュリティに関してのポリシーである。 # 趣旨・目的 [esa.io](https://esa.io)の利用者が、安心してサービスを利用できるようにするため、当社の情報セキュリティに対するポリシーを示し、社員全員がこれを尊守する。 # 適用範囲 セキュリティポリシーが適用される人は当社のコーポレートサイト [team.esa.io](https://team.esa.io/)に記載される社員全員とする。 * 櫻井(赤塚)妙子 * 深谷篤生 * 越川直人 適用される情報資産は、後述の**当社の取り扱う情報資産について**へ記載する。 # 位置付け 本セキュリティポリシーは当社の他の規定よりも優先される。 # 運用・監査体制 ## 情報セキュリティに対する責任者 本セキュリティポリシーを定め、運用と監視を行う。 * 越川直人 ## 情報資産取扱の責任者 本セキュリティポリシーに則り情報資産を取り扱う。 * 深谷篤生 ## セキュリティポリシーの見直し 月に一度、情報資産取扱の責任者と経営メンバーにおいて以下の項目のレビューを行い、必要があれば改定を行う。 * セキュリティポリシーに沿った運営がされているか * 組織環境、業務環境、法的環境、技術的環境等の変化に対応しているか 具体的には社内のslack reminderを用いて、見直し実施をお知らせし、見直しを行う。 ## セキュリティポリシーの改訂の承認 esaの該当記事に変更箇所のdiffを貼り、それに対して社員全員が「LGTM」とコメントすることで承認したものとする。 # 当社の取り扱う情報資産について ## 情報資産取扱の責任者 セキュリティーポリシーの制定と改定、組織内の尊守に責任を持つ。 * 深谷篤生 ## 運営サポート業務を行うもの 情報資産を取扱い、運営サポートを行うものを以下に定める。 * 櫻井(赤塚)妙子 * 深谷篤生 * 越川直人 ### [esa.io](https://esa.io)における情報資産 各チームの`/team`からアクセス出来る**チーム情報**と、**ユーザー情報**、**投稿情報**の3つに情報資産を分類する。 1. チーム情報 1. ユーザー情報 1. 投稿情報 チーム情報、ユーザー情報については、運営サポート業務に限り、**運営サポート業務を行うもの**へ**管理者用ページの**アクセス許可を与える。投稿情報に関しては、後述するDB管理者以外に一切のアクセス権限は与えない。またDB管理者においても特別の事情がない限り一切の投稿情報へのアクセスは行わないものとする。 #### 管理者用ページ 運営サポート業務を行うものが、その業務範囲内において、以下の情報を閲覧できるページを指す。 1. チーム情報 1. ユーザー情報 管理者用ページは正しいアクセス権限持ったユーザーのみがアクセス出来ることを自動テストにて担保する。 ## 保存しない情報 * パスワードの平文 * クレジットカードの情報 ### クレジットカードの情報について PAY.JPと紐付けるtoken情報のみ保持する。PAY.JPへのアクセスキーなどは、暗号化して保存している。 暗号化とは、環境変数の暗号化を指す。 ## 社員の情報資産の取扱誓約 情報資産の取扱範囲について、全社員にそれぞれの役割におけるアクセス権限の範囲と責任について合意書を締結するものとする。 # 社員について ## 社員の教育・訓練 セキュリティポリシーに関する意識向上のための適切な教育・訓練として、以下の教育動画を定期的(約半年に一度を目安とする)に閲覧することを義務付ける。 > [映像で知る情報セキュリティ ~映像コンテンツ一覧~:IPA 独立行政法人 情報処理推進機構](https://www.ipa.go.jp/security/keihatsu/videos/) ## 社員がセキュリティーポリシーに違反した場合 違反のレベルに応じて、適切に対処する。 ## 社員の入社時・退職時の対応 会社/情報セキュリティ規定/入社時・退職時のマニュアル(社内文書)に記載する。 ## 社員の報告責任 業務において発見あるいは疑いをもった情報システムの脆弱性や情報セキュリティインシデント(サービス停止、情報の漏えい・改ざん・破壊・紛失、ウイルス感染等)について、従業員はすみやかに当社のslackにて報告を行う。後日、[docs.esa.io](https://docs.esa.io)にまとめる。 ## 業務委託先について 業務委託先事業者、顧問などについても社員と同等のセキュリティポリシーの尊守を契約書に盛り込み、義務付ける。 # コンプライアンス ## 監査ログ サービスの提供および継続上重要な記録として以下の監査ログを取得している。 * AWSの監査ログ * 管理者ページの監査ログ ## 情報の利用許可 * 本ポリシーで定める情報へは運営サポート業務を行う者が業務で利用する各自のマシンからのみアクセス出来るものとする。 * 利用するマシンにはPCのロック設定・暗号化を行う。 # サービス運用に関わるセキュリティポリシー ## データベース AWSのRDSを利用する。 ### データベース管理者 運用に必要なデータベースの設定・管理などの作業を行う権限を持つ者を指す。 * 深谷篤生 * 越川直人 ## インフラ 主な情報は、[サービス運用ポリシー内のインフラ情報](https://docs.esa.io/posts/261#9-0-0)を参照のこと。 ### インフラ管理者 運用に必要なインフラの設定・管理などの作業を行う権限を持つ者を指す。 * 深谷篤生 * 越川直人 ## インフラに関するアカウント AWSのIAMを用いて、インフラ管理者が行う。 ## ミドルウェアのバージョン秘匿 Webサーバ、OSデフォルトの名称やバージョン情報をエラー情報などに表示しない。 ## SSLのセキュリティポリシー [Elastic Load Balancing で事前定義された SSL のセキュリティポリシー](http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/classic/elb-security-policy-table.html) の **TLS-1-2-2017-01** を利用。 ## SSL通信の強制 HTTPへのアクセスはHTTPSへリダイレクトしている。 ## ユーザーパスワードの取扱 Googleアカウントでのログインのみ許可している。 > 名前とパスワードのガイドライン > https://support.google.com/a/answer/33386?hl=ja に準拠。 # 開発に関わるセキュリティポリシー ## 脆弱性対策 サービスの提供に用いるアプリケーション等の新規開発時や改修時において、定期的な実施時と同等またはそれ以上の水準で脆弱性診断を行い、その結果に基づいて対策を行っている。 ### 脆弱性回避の例 * OSコマンドインジェクション対策 * SQLインジェクション対策 * パス・トラバーサル対策 * シンボリック攻撃対策 * CSRF対策 * 入力検査において全項目が網羅されていない * クライアント側スクリプトの検査ロジックが迂回されないこと * 数値範囲検査において攻撃を見逃さないこと * バックドアの回避 ### 脆弱性対策方法 > [brakeman](https://github.com/presidentbeef/brakeman) > A static analysis security vulnerability scanner for Ruby on Rails applications を用いてソースコードの静的解析により対策を施している。 ## ソースコードレビュー アプリケーションのソースコードレビューは、開発者とは別の第3者により実施され、セキュリティの観点を含んで確認を行う。 具体的にはGitHub上の[Pull Request](https://help.github.com/articles/about-pull-requests/)を用いて行う。 ## エラー内容の考慮 エラー発生時の表示メッセージに、問い合わせなどに必要な情報のみを記載し、内部構造が推測できるような不必要な情報を表示しない。 また、その際のサーバー内のログ出力において、開発・監視に直接関わることの少ない、ユーザーのプライバシーに関わるような情報を出さない。 # セキュリティ事故や、サービス利用に影響がある障害があった場合 必要な場合は全サービスをメンテナンスモードへ移行後、直ちに各チームのownerへメールにて報告する。 # その他セキュリティに関する項目 - [help/スクリプトタグの埋め込み制限 - docs.esa.io](https://docs.esa.io/posts/165) - [help/記事・スライドの外部公開のしかた - docs.esa.io](https://docs.esa.io/posts/110) - [help/ファイルアップロード先に独自のS3 Bucketを設定する - docs.esa.io](https://docs.esa.io/posts/81) - [ReleaseNotes/2017/04/28/クレジットカード決済サービスの切り替え完了のお知らせ - docs.esa.io](https://docs.esa.io/posts/213)
この文書は、esa LLC(以降、当社と呼ぶ)の運営する、esa.ioが取り扱う情報セキュリティに関してのポリシーである。
esa.ioの利用者が、安心してサービスを利用できるようにするため、当社の情報セキュリティに対するポリシーを示し、社員全員がこれを尊守する。
セキュリティポリシーが適用される人は当社のコーポレートサイト team.esa.ioに記載される社員全員とする。
適用される情報資産は、後述の当社の取り扱う情報資産についてへ記載する。
本セキュリティポリシーは当社の他の規定よりも優先される。
本セキュリティポリシーを定め、運用と監視を行う。
本セキュリティポリシーに則り情報資産を取り扱う。
月に一度、情報資産取扱の責任者と経営メンバーにおいて以下の項目のレビューを行い、必要があれば改定を行う。
具体的には社内のslack reminderを用いて、見直し実施をお知らせし、見直しを行う。
esaの該当記事に変更箇所のdiffを貼り、それに対して社員全員が「LGTM」とコメントすることで承認したものとする。
セキュリティーポリシーの制定と改定、組織内の尊守に責任を持つ。
情報資産を取扱い、運営サポートを行うものを以下に定める。
各チームの/team
からアクセス出来るチーム情報と、ユーザー情報、投稿情報の3つに情報資産を分類する。
チーム情報、ユーザー情報については、運営サポート業務に限り、運営サポート業務を行うものへ管理者用ページのアクセス許可を与える。投稿情報に関しては、後述するDB管理者以外に一切のアクセス権限は与えない。またDB管理者においても特別の事情がない限り一切の投稿情報へのアクセスは行わないものとする。
運営サポート業務を行うものが、その業務範囲内において、以下の情報を閲覧できるページを指す。
管理者用ページは正しいアクセス権限持ったユーザーのみがアクセス出来ることを自動テストにて担保する。
PAY.JPと紐付けるtoken情報のみ保持する。PAY.JPへのアクセスキーなどは、暗号化して保存している。
暗号化とは、環境変数の暗号化を指す。
情報資産の取扱範囲について、全社員にそれぞれの役割におけるアクセス権限の範囲と責任について合意書を締結するものとする。
セキュリティポリシーに関する意識向上のための適切な教育・訓練として、以下の教育動画を定期的(約半年に一度を目安とする)に閲覧することを義務付ける。
違反のレベルに応じて、適切に対処する。
会社/情報セキュリティ規定/入社時・退職時のマニュアル(社内文書)に記載する。
業務において発見あるいは疑いをもった情報システムの脆弱性や情報セキュリティインシデント(サービス停止、情報の漏えい・改ざん・破壊・紛失、ウイルス感染等)について、従業員はすみやかに当社のslackにて報告を行う。後日、docs.esa.ioにまとめる。
業務委託先事業者、顧問などについても社員と同等のセキュリティポリシーの尊守を契約書に盛り込み、義務付ける。
サービスの提供および継続上重要な記録として以下の監査ログを取得している。
AWSのRDSを利用する。
運用に必要なデータベースの設定・管理などの作業を行う権限を持つ者を指す。
主な情報は、サービス運用ポリシー内のインフラ情報を参照のこと。
運用に必要なインフラの設定・管理などの作業を行う権限を持つ者を指す。
AWSのIAMを用いて、インフラ管理者が行う。
Webサーバ、OSデフォルトの名称やバージョン情報をエラー情報などに表示しない。
Elastic Load Balancing で事前定義された SSL のセキュリティポリシー の TLS-1-2-2017-01 を利用。
HTTPへのアクセスはHTTPSへリダイレクトしている。
Googleアカウントでのログインのみ許可している。
名前とパスワードのガイドライン
https://support.google.com/a/answer/33386?hl=ja
に準拠。
サービスの提供に用いるアプリケーション等の新規開発時や改修時において、定期的な実施時と同等またはそれ以上の水準で脆弱性診断を行い、その結果に基づいて対策を行っている。
brakeman
A static analysis security vulnerability scanner for Ruby on Rails applications
を用いてソースコードの静的解析により対策を施している。
アプリケーションのソースコードレビューは、開発者とは別の第3者により実施され、セキュリティの観点を含んで確認を行う。
具体的にはGitHub上のPull Requestを用いて行う。
エラー発生時の表示メッセージに、問い合わせなどに必要な情報のみを記載し、内部構造が推測できるような不必要な情報を表示しない。
また、その際のサーバー内のログ出力において、開発・監視に直接関わることの少ない、ユーザーのプライバシーに関わるような情報を出さない。
必要な場合は全サービスをメンテナンスモードへ移行後、直ちに各チームのownerへメールにて報告する。