🦆
教育情報セキュリティポリシーに関するガイドライン を眺めてみる
なぜ作成したのか
- 業界ごとのセキュリティポリシーの違いって結構気になりますよね
観点
- 教育情報を取り扱うWebサービス構築ベンダーの立場で理解しておくべきポリシー
をまとめてみたい
参考
教育情報を取り扱うWebサービス構築ベンダーの立場で理解しておくべきポリシー
1. 基本的な立ち位置と背景の理解
- 教育現場は、児童生徒・保護者・教職員といった多様なユーザーが関わり、個人情報・成績・指導記録・健康情報など高機密な情報を日常的に扱う環境です。
- そのため、Webサービスベンダーには「一般的なITセキュリティ」以上の配慮が求められます。
2. 理解すべき主要なポリシーと対策
◆ 情報資産の分類と重要性の認識
- ベンダーとして扱うデータには、以下の4分類があり、それぞれに適切なセキュリティ対策が必要です。
| 分類 | 内容 | 例 |
|---|---|---|
| Ⅰ類 | 甚大な被害リスク、要配慮個人情報 | 指導要録原本 |
| Ⅱ類 | 大きな被害リスク、機密性高 | 成績・進路情報 |
| Ⅲ類 | 中程度リスク、学習記録等 | ワークシート、出席簿 |
| Ⅳ類 | 公開情報 | 学校HP、パンフ |
- サービス設計段階で、これら情報をどう分類し、どう格納・アクセス制御するかを定めておく必要があります。
◆ 外部委託者としての義務と責任
-
Webサービスベンダーは 外部委託先 として位置づけられ、「教育情報セキュリティポリシー」の対象です。以下が重要です：
- 業務委託契約書にセキュリティ義務の明記
- 秘密保持契約（NDA）の締結
- アクセス権管理（委託社員含む）
- 退職・異動者の権限廃止
- 端末の管理（MDM・暗号化・リモートワイプ）
- 監査対応（ログ・バックアップ保存義務）
◆ 技術的セキュリティ対策の具体例
| 対策カテゴリ | 実装例 |
|---|---|
| アクセス制御 | ロールベースアクセス制御（RBAC）、多要素認証 |
| 通信の暗号化 | TLS 1.3以上を必須、VPN経由アクセスなど |
| データ暗号化 | AES-256による保存時暗号化（At Rest）、転送時暗号化（In Transit） |
| ログ管理 | アクセスログ・操作ログの保存と定期レビュー |
| マルウェア対策 | サーバ・クライアント双方に最新の対策実施 |
| 可用性対策 | 冗長構成（クラウドマルチAZ）、バックアップポリシー明示 |
◆ クラウド利用時のポリシー対応
特にSaaS型クラウドサービスとして提供する場合、以下が重要です：
- 第三者認証（ISO/IEC 27001, ISMAP等）取得推奨
- 日本国内リージョンでのデータ保存
- 利用規約・プライバシーポリシーの明確化と同意取得
- 自治体要件に対応した契約形態の提供（例：専用環境の提供）
- サービスレベル合意（SLA）の明示
◆ ユーザー教育とインシデント対応支援
教育現場では、教職員・児童生徒のセキュリティリテラシー が課題とされます。ベンダーとしては以下もサポート可能です：
- 管理者／利用者マニュアルの整備
- 操作ミスによる情報漏えい防止のガイド
- インシデント対応フローの整備と教育委員会との連携
- ユーザー向けの情報モラル教材提供（特に児童生徒向け）
3. ガイドライン遵守のための開発・運用チェックポイント
| フェーズ | チェックポイント |
|---|---|
| 要件定義 | 情報資産分類、教育委員会の運用ルール確認 |
| 設計 | 最小権限設計、パスワードポリシー、クラウド選定 |
| 実装 | ログ取得機能、監査証跡保存、暗号化 |
| テスト | 脆弱性スキャン、インシデント対応訓練（机上含む） |
| 運用 | 月次報告、SLA監視、障害連絡フローの整備 |
まとめ：Webサービスベンダーとしての姿勢
- 教育現場の特殊性（児童生徒・保護者・教員の多層的関与）を理解
- 自治体や教育委員会との協働関係を構築
- 継続的改善と透明性の高い運用（見直し・評価・報告）を実施
- 強固な技術基盤＋人的支援体制の両輪で信頼性を担保
補足：アジャイル開発に対するスタンス
-
「教育情報セキュリティポリシーに関するガイドライン」および「ハンドブック」では基本的にウォーターフォール型開発を前提としたような構成になっています。
-
しかし、近年のクラウドベースのサービス提供や自治体のDX推進の流れを踏まえると、アジャイル開発も想定に入れておくべき です。
-
令和7年3月改訂版の文書では、アジャイル開発に直接言及する記載は明確ではありませんが、次のような観点で アジャイル開発に対応可能な姿勢 や指針が読み取れます。
アジャイル開発に関する示唆と対応ポイント
1. 「実施手順」は現場実情に応じて柔軟に策定可と明記
実施手順については、教育委員会がひな形を策定し、各学校が現場の実情に応じて策定すべきである
- これは、固定化された手続きではなく、反復的改善（Iterative Improvement）や段階的展開を前提とするアジャイルの考え方に合致します。
- サービスの実装や改善をスプリント単位で行う場合も、ひな形に従ってセキュリティ対策を段階的に組み込む運用が容認されていると考えられます。
2. セキュリティ対策を「随時反映」する柔軟性が求められている
- 特にクラウドサービスに関する記述では、「日進月歩で進化する新しいサービスの取り入れ」「セキュリティ対策の随時更新」が示されており、アジャイル開発の特徴である 継続的デリバリー・適応的セキュリティ設計 が前提にされていると解釈できます。
3. 「対策基準」と「実施手順」を分ける設計はアジャイルにフィット
-
「対策基準」 ＝ 守るべき原則・最低限のセキュリティ要求
-
「実施手順」 ＝ プロジェクトごとに柔軟に適用可能
-
という構造は、アジャイルプロジェクトにおいても、共通基盤としてのセキュリティポリシーを保ちながら、スプリントごとに手順を更新・改善できる設計になっています。
4. 「評価・見直し」のプロセスの中にアジャイル的フィードバックサイクルを内包
- 第10章では、自己点検・監査・再策定のサイクルが明示されており、これはアジャイル開発における スプリントレビューやレトロスペクティブに相当するPDCA的要素です。
✅ アジャイル開発ベンダーが留意すべき実務ポイント
| 項目 | 内容 |
|---|---|
| ✅ スプリント毎のセキュリティチェック | 要件定義時に分類された情報資産ごとに、脅威分析と保護対策を定期的にレビュー |
| ✅ ドキュメントの逐次更新 | 「完了の定義（DoD）」にセキュリティ関連ドキュメント（例：リスク評価表、アクセス権変更履歴）の更新を組み込む |
| ✅ POC・試行段階からポリシー準拠を意識 | 本番前の段階でも、教育委員会の「承認された環境」でテストを実施し、私的端末や非公式サービスの利用を排除 |
| ✅ ステークホルダー参加型セキュリティ設計 | 教育委員会や学校関係者（情報セキュリティ管理者）との連携を保ちながら、仕様変更やリリース判断を行う |
まとめ：ガイドラインはアジャイル開発を禁止していないとも解釈できそう
- 明確な言及はないが、柔軟性と現場適応性を前提にした設計
- セキュリティ基準の遵守を前提としつつ、実施手順は柔軟に運用可能
- POC〜本番展開を段階的に進められるアーキテクチャが望ましい
所感
- 地方自治体の三層分離と似たような感じのネットワーク分離（校務系／校務外部接続系／学習系）は前提
- 強固なアクセス制御対策と合わせて、タテとヨコの構成はわかりやすい
Discussion