[Qiita 様依頼事項]サービスを公開前にすること

サービスを公開前にすること

余談：設計段階で、スケールしやすい構成にすること

1. 例：RDB or NoSQL？
   1. 特に、Google Cloud Spanner と Cloud Firestore は秀逸
2. AMD64(x86_64) or ARM?
   1. 時代の流れは ARM（コスパ最高）
3. 例：依存性を少なくし、ミニマムに作る(Everything should be made as simple as possible, but no simpler.)
4. 特にこだわりがない場合、Go をおすすめ。自信があるなら Rust がすごくいいけど PaaS でのサポートはまだないので注意（しかもまだ言語自体が発展途上、ただし、PaaS でのサポートは時間の問題な気はする）
5. PaaS や SaaS のようなマネージドを使おう、それが無理なら IaaS
   1. クラウドのマネージドサービスで多重化した方が、ディスク故障にも対応しやすいから行政指導とか入りにくいよ
   2. 特にこだわりがなければ AWS がおすすめ（規模の経済）
   3. Azure は Windows の開発元(Microsoft)が運用しているため、利用規約に抵触しないので、クライアント版の Windows （Windows 10 とか）も利用可能（Azure のシェアが伸び続ければ独占禁止法に抵触するかも）
      1. もちろん Windows Server も利用可能
   4. Google Cloud Platform
      1. 性能がとても素晴らしいが、使い方に癖があって CLI が苦手な方にはやや使いにくい
      2. Azure のシェアを超えることができない場合サービスが終了する可能性があって将来性に難あり（Google のお家芸、急なサービス停止）

コードの静的解析 + エビデンス

1. Coverity
2. CodeScan

機械的なセキュリティチェック+エビデンス

1. XSS や SQL インジェクション, CSRF
   1. VAddy
   2. AppScan
   3. OWASP
2. 使用しているライブラリに存在する脆弱性の確認
   1. OWASP Dependency Check 等
   2. npm audit
   3. フロント、バックエンド両方チェックしよう
3. 負荷試験（CPU/Memory）
   1. まずはサイジング
   2. Oracle Load Testing
   3. JMeter 等
4. 認証（ログイン、ログアウト）
   1. 複数のクライアントからログイン・ログアウトを大量に行う
   2. 認証は特に大事なので意図したユーザとは違うユーザでログインしてしまうといった致命的な不具合が生じないことを確認
5. 二段階認証
   1. TOTP
   2. Twilio(SMS)

ログ（適切なログレベルに基づく様々なログ、その保管期間）

1. おすすめ（私見）
   1. Google Cloud Logging（直近のログ閲覧） + Google BigQuery（永久、シンクでつなぐだけ）
   2. Elasticsearch + Kibana（Elastic は運用〔バックアップ、アップグレード〕が面倒くさいので、本家のマネージドサービスである Elastic Cloud を推奨）
2. AWS を利用しているのであれば Amazon CloudWatch Logs
3. ログ保管期間
   1. 最低 5 年はログを保持する事、できれば 10 年保持する事
      1. 根拠 民法 166 条（債権等の消滅時効）、724 条（不法行為による損害賠償請求権の消滅時効）
      2. Cloud Logging や BigQuery を使えば 10 年保存は十分に実現可能

ウェブページのレイアウトに関する注意事項

よそのサービスに「依拠」したレイアウトにしてしまうと不正競争防止法にかかる恐れがあるため、デザインを真似ることはやめ、ちゃんと自力でデザインすること

PageSpeed Insights（Chrome の開発者ツール Lighthouse でも可能）

個人情報を取得する場合

1. プライバシーポリシー
2. 万が一流出してしまった場合のフローを確定し周知しておく（以下を「速やかに」実施できるようにしておく事）
   1. 個人情報保護委員会のホームページにある報告フォームにて報告
   2. 流出させてしまった個人にも報告（2次被害を防ぐため）
      1. 速やかに実施できるよう、文章の内容、お詫びの内容も決めておくこと

特定商取引に当たる場合

1. 個人が運営する場合でも「業として営む」場合には該当するので注意（詳細は施行通達 特定商取引法の通達改正・一方的に送り付けられた商品に関するチラシ等の公表について | 消費者庁を参照）
2. 特定商取引法に基づく「表記」及び「返品特約」は必須

景品表示法（広告・プレゼント）

1. 嘘、大げさ、まぎらわしい

消費者契約法（BtoC）

1. 不実告知、断定的判断の提供、故意・重過失による不告知など

利用規約

1. （定型）約款（可能であれば「合意擬制〔みなし合意〕」が働くように定型約款にしておく事が重要〔定形取引、内容の合理性、利用規約内に契約内容とすることを目的とする記載〕）
2. 免責事項
   1. ユーザー同士の紛争
   2. プラットフォーム型のサービスの場合、出品されている商品の品質保証を事業者がしないこと
3. 権利関係（投稿された情報の権利関係）
4. 裁判所の管轄（運営とユーザーが争議になった場合）
5. モニタリングを行うこと
   1. 不適切なユーザ（違法行為を行っているユーザや、利用規約に禁止するユーザ）がいないか随時探索、該当ユーザのアカウントの制限・停止措置することが可能な旨を記載

既にサービスを公開済みで、サービスの更新を本番環境にデプロイする前の場合

1. 本番環境とステージング環境の両方で、上記 PageSpeed や Google Stackdriver Profiler, Oracle Load Testing などを用いてログイン、ログアウト、編集、表示一通りの操作を行い、性能が劣化していないことを確認する

サービス公開後にすること

SSL

1. SSL Server Test
2. Chrome 開発者ツールの「セキュリティ」

WAF（必須）

1. Cloudflare（おすすめ、WAF 以外もカバーもしてくれ、無料でできる範囲が広いので非常におすすめ）
2. AWS WAF（AWS を利用したサービスの場合はこちら）

ログの正確性の確認

1. 不正なアクセスがないかチェック
2. 運用後のログの流れ具合からアラートのしきい値を見直す
3. ログレベルの見直しも実行する

DNSSEC（Route 53 でも最近利用可能になった）

1. DNSViz

プロファイラ

1. （おすすめ）Google Stackdriver Profiler(Google Cloud Profiler)
2. Dynatrace
3. Flight Recorder
4. Amazon CodeGuru Profiler
5. 他、サービスの運用に影響を与えないレベルでプロファイラを入れ、徐々にサービスを改善していく事、メモリリークも本番環境で運用して初めて気づくこともあるため CPU/Memory 両方プロファイルしておくこと

死活監視

1. Zabbix
2. Amazon CloudWatch
3. k8s の Liveness Probe, Readiness Probe, Startup Probe とかで自動復旧されるのが理想