Portfolioこのトピックについて
業務システムでは、セキュリティが何より重要です。不正アクセスやデータ漏洩は、会社の信用を失墜させかねません。このプロジェクトでは、中小企業でも安心して使えるよう、多層防御のセキュリティ設計を採用しました。
セキュリティの多層防御
1つの防御策だけに頼るのは危険です。複数の層で防御することで、1つが突破されても次の層で守れます。
秘密トークンで正規のアクセスか確認
短時間の大量リクエストをブロック
不正なデータを処理前にはじく
暗号化ストレージ + 自動更新
第1層: トークン認証
GASからの通信には、32文字以上の秘密トークンを使用します。このトークンを知らない第三者からのアクセスは自動的に拒否されます。
| 項目 | 内容 |
|---|---|
| トークンの長さ | 32文字以上（推測が困難） |
| 送信方法 | HTTPヘッダーに含めて送信 |
| 照合場所 | サーバー側の環境変数と比較 |
| 不一致時 | 即座に401 Unauthorizedを返却 |
トークン管理のポイント
トークンはGASの設定画面（スクリプトプロパティ）で管理するため、万が一漏洩してもすぐに変更可能です。コードを修正する必要はありません。
第2層: レート制限
短時間に大量のリクエストが来た場合、自動的にブロックする仕組みです。
クライアントIP + トークン末尾8文字で識別
過去1分間のリクエスト数をチェック
レート制限で防げること
- 悪意のある大量アクセス: 攻撃者によるサービス妨害
- 操作ミス: ボタンの連打による重複処理
- 無限ループ: プログラムバグによる無限リクエスト
レスポンスヘッダーでの通知
APIレスポンスには、残りのリクエスト回数が含まれています。
| ヘッダー | 意味 | 例 |
|---|---|---|
| X-RateLimit-Remaining | 残りリクエスト回数 | 45 |
| X-RateLimit-Reset | リセット時刻（Unix時間） | 1705363200 |
第3層: 入力値検証
送信されたデータが正しい形式かどうか、処理前に厳密にチェックします。
| 項目 | 検証内容 | 不正な例 |
|---|---|---|
| 日付 | yyyy-mm-dd形式 | 2024/01/15（スラッシュ区切り） |
| 金額 | 数値（小数点以下3桁まで） | 1,000（カンマ入り） |
| タグ | 最大10個まで | 11個以上の指定 |
| べき等性キー | 8文字以上 | 短すぎるキー |
検証で不正が見つかった場合
処理を開始する前にエラーを返却します。これにより、不正なデータが請求書サービスに送信されることを防ぎます。
検証エラーの場合、どのフィールドが、なぜ不正なのかを詳細に返却します。原因特定が容易になり、修正作業がスムーズになります。
第4層: 認証情報の安全管理
請求書サービスへの接続に必要な認証情報（アクセストークン）は、特別な管理が必要です。
認証情報管理の3つの工夫
| 工夫 | 説明 | メリット |
|---|---|---|
| 暗号化ストレージ | Redisなどの暗号化されたクラウドストレージに保管 | 漏洩リスクの低減 |
| 自動更新 | 有効期限60秒前に自動で新しいトークンを取得 | 手動管理不要 |
| 分散ロック | 同時アクセスでも重複更新を防止 | トークンの不整合を防ぐ |
APIを呼び出す前にトークンを取得
残り60秒以上あるか確認
有効なトークンでリクエスト
分散ロックの仕組み
複数のリクエストが同時にトークン更新を試みると、以下の問題が発生します。
- 同じトークンを何度も更新（無駄なAPI呼び出し）
- 古いトークンと新しいトークンが混在（不整合）
分散ロックにより、同時に1つのインスタンスだけがトークン更新を行えるようにしています。
セキュリティ設計のまとめ
| 脅威 | 対策 | 防御層 |
|---|---|---|
| 不正アクセス | トークン認証 | 第1層 |
| DDoS攻撃 | レート制限 | 第2層 |
| 不正入力 | 入力値検証 | 第3層 |
| 認証情報漏洩 | 暗号化ストレージ + 自動更新 | 第4層 |
この設計で実現できること
運営側にとって
- セキュリティ対応の工数削減: 自動化された保護機構
- インシデント対応の容易さ: トークン変更だけで対処可能
- 監査対応: 構造化ログで履歴を追跡
利用者にとって
- 安心して利用: 多層防御で守られている
- 透明性: レート制限の残り回数がわかる
- 迅速なエラー通知: 問題があればすぐに把握