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