見出し画像

国の学校向けセキュリティガイドラインを無視してシステム構成を考えてみた②

前回の記事が結構反響がありましたので、今日はその続きを。
考えたシステム構成のポイントの補足などを書いてみたいと思います。前回記事は以下です。合わせてお読みいただけたらと。

前回のおさらい

最初に前回記事のおさらいを。
まずは市場全体や国の動きなどのトレンドと、現場の課題感のを整理。
要求定義のプロセスです。

画像1

そのうえで、以下のポイントでアーキテクチャを考えています(このときに国の「教育情報セキュリティポリシーに関するガイドライン」の対策例は無視しています(一部制限事項の除外))。

1. ネットワークはインターネット接続のみ(閉域網(VPN)は使わない)
⇒ 校務・学習のネットワーク分離は行わない
2. 利用システムはSaaS(パブリッククラウド)に徹底する
⇒ クラウド・バイ・デフォルトに則る
3. セキュリティ対策はクラウド側とエンドポイント(情報端末)で実施
⇒ 校内やセンタ集約されたシステムなどでは行わない
(おまけ)4. 学びの入口・集約として学習eポータルを
⇒ 折角ネットワーク分離が解消されるならデータ連携も

それらを踏まえた概念図はこちら。

画像2

今日はこの概念図の設計上のポイントの補足と具体例などをあげていきます。

最大の難所。「利用システムはSaaS(パブリッククラウド)に徹底する

今回のシステム構成のポイントは、おまけの4(=学習eポータル)を除くと以下の3つです。

1. ネットワークはインターネット接続のみ(閉域網(VPN)は使わない)
2. 利用システムはSaaS(パブリッククラウド)に徹底する
3. セキュリティ対策はクラウド側とエンドポイント(情報端末)で実施

1はある意味で"キメ"の問題です。ここがガイドラインの対策例と異なっていることは課題ですが、要求定義を満たすための最良構成を考えるうえで必要だったので、心を強く持つしかありません。

3は論理的な整理と選択で対応が可能です。1を決めたら後はセキュリティ対策の実装方法なので、問題を細分化し、最適なソリューションを探していくだけです。これが難しいというところもあると思いますが、そこは具体例含めて後述してみます。

そして2の「利用システムはSaaS(パブリッククラウド)に徹底する」が難しい

note画像

これ「クラウド・バイ・デフォルト原則」と同義なのですが、ほとんどのケースでやりきれていない。国の現行版ガイドラインも、結局のところセキュリティ対策例ではやりきれていないぐらいです。

それは特定の仕組みやソフトウェア、サービスへの拘りを捨て、ある程度の妥協が必要だからです。
調達を担当される方に拘りがなくとも、現場では「●●がないと困る」のようなことが良くあります。この「●●」が個別にサーバを立てないといけないアプリだったりすると厄介です。
「●●ですが、SaaS版も提供していますー」という謳い文句があったりしますが、良く見るとNAT越えができず実態はVPN組んでプライベートアドレスで設計しないといけない「なんちゃってSaaS」もあるので困ってしまいます。

でもその拘りのアプリ、必ず代替するSaaSがあります。

ロイロ・ノートもブラウザ版をリリースしてくれています。Sky Menuもブラウザ・クラウド版もあります。ウィルス対策など、インストールが必須となるアプリもありますが、MDMなどで配信できるようにして、管理サーバはクラウド版を使えるものにできるはず。
一部機能が充足しない可能性はありますが、ここはグッと堪えて、また、なんとか現場を説得して、SaaS版を探して選択する。

一定の諦めが必要な可能性がありますが、そこでの損失より、全体のアーキテクチャを見直したときに得るものの方が格段に大きいはずです。
先生方が自宅で作業ができるようになったり、ICT支援員の方が現場に行かないと対処できない作業が大幅に減ったり、教育委員会の方が(またはその委託を受けている事業者が)運用するシステムが一本化されたり、とトータルコストの減少・人員稼働の削減は大きいはずです。
1つのアプリへの拘りが結果としてトータルでの損をしている、というのはこの業界では「あるある」なので、ここを粘り強くやっていく必要があります。

また、SaaS選択時のクラウドサービスに対するセキュリティ上の確認点は、教育情報セキュリティポリシーに関するガイドラインのp120-136に記載があるので、ご確認いただけたらと。

困ったときはICT活用教育アドバイザーに相談も

この辺で困ったら、文部科学省の「ICT活用教育アドバイザー」に相談してみるのも良いかもです。

私もこのアドバイザーの末席に名を連ねていますので、指名はできないっぽいですが、相談は可能です。
ちなみに私がアドバイザーとして支援させてもらった場合は、同時に世のネコを支援することになります。こんな感じ。

ネコ

「なるほど分からん」という方は、こちらもご覧いただけたらと。
Googleで「ICT活用教育アドバイザー ネコ」と検索すると、文科省の事業説明より上に出てきます(そんな検索するヤツはいない)。

ネットワークはインターネット接続のみ(閉域網(VPN)は使わない)

アプリ・システムの全てをSaaSで選択できたら、個別にデータセンタを借りてサーバを構築したりすることが不要になり、「1. ネットワークはインターネット接続のみ(閉域網(VPN)は使わない)」の部分、ネットワークもインターネットへのアクセスだけで良くなります。

noteでも以前書いていますが、GIGAの関係で学校では端末接続数が爆発的に増えています。

政府統計によると5,000人の従業員を抱える企業数は579社。5000人以上の児童生徒を抱える教育委員会数は512自治体。
企業で言えば1,000人超はかなりの大企業ですが(正確な定義だと製造業では300人超で中小企業ではなくなる=大企業です...。学校だとサービス業かもなので100人?)、児童生徒数が1,000人超で見ると1179自治体。

少し乱暴に言えば、半分以上の自治体は、日本の企業で言い換えれば上位0.1%に入るほどの大企業並みのインターネット接続環境を運用する必要があるということです。

私は以前から書いている通り、学校からの直接接続=ローカルブレイクアウトのネットワーク構成をおススメします。

1年以上前の記事ですが、私のnoteのなかでは今もアクセス数の上位をキープしています。むしろ最近、GIGAで使われだしているせいか、またアクセスが増えてきた感じ。

ただ、ちゃんと設計できるのであればセンタ集約型でも勿論OKです。その場合は、上記の通り「日本の企業の上位0.1%に相当する規模での運用になる」ということは頭に入れ、しっかりシステム全体を設計できる事業者と一緒に進めていくを留意していただくことをおススメします。

(追記)
1点書き忘れていました。
各校からインターネットに出ていく構成にする際には「IPoE方式」かつ「固定IPアドレスが1つ以上ある」サービスを選択することをおススメします。
前者のIPoE方式については、こちらを見てもらえたらと。要は新しい仕組みで速くなる可能性が高い、ぐらいに理解してもらえればOKです。
また、後者の「固定IP」については、アクセス元の特定(学校からのアクセスかを判別したりする)など、後々のセキュリティ対策で必要となってくるためです。価格が上がりますが、そこは必要経費と捉えていただけたらと。

セキュリティ対策はクラウド側とエンドポイント(情報端末)で実施

最後は具体的なセキュリティ対策の内容です。
主な対策対象を「クラウド側とエンドポイント(情報端末)」としているので、以下のあたりです。

セキュリティ対策

上記の①から③までをこの後に書かせてもらおうかと思っていましたが、、、
この時点で3,000字近くなっているので、次回にしたいと思います。
本当は2回で終わらせるつもりだったのですが、、、
長いと読んでくれない、とも言われることが多いので、今回はこの辺で。

おわりに。システム全体を俯瞰して設計すること。

具体的なセキュリティ対策の内容はサービスの選択を期待していた方もいたのでは。中途半端な内容になってしまい申し訳ないです。
次回、できるだけ早くアウトプットするようにします。
3回に分けて記載してしまうことになるので、要点だけをまとめた1記事を書くとより読みやすいかもですね。時間があればやってみます。

今回書いたのは結局のところ利用システムはSaaS(パブリッククラウド)に徹底するをやりきることの重要性でした。
やりたいことをまとめる作業=要求定義は最も重要な工程ですが、そのなかで「このアプリを入れたい」のようなことに固執すると、システム全体で体現すべき価値が大きく減衰することが多々あります。

2回同じことを書いてしまいますが、

一定の諦めが必要な可能性がありますが、そこでの損失より、全体のアーキテクチャを見直したときに得るものの方が格段に大きいはずです。
先生方が自宅で作業ができるようになったり、ICT支援員の方が現場に行かないと対処できない作業が大幅に減ったり、教育委員会の方が(またはその委託を受けている事業者が)運用するシステムが一本化されたり、とトータルコストの減少・人員稼働の削減は大きいはずです。
1つのアプリへの拘りが結果としてトータルでの損をしている、というのはこの業界では「あるある」なので、ここを粘り強くやっていく必要があります。

と書いた通り、システム全体を俯瞰してアーキテクチャを設計することは、要求定義と同レベルに重要なことです。

嫌なことを書きますが、学校教育のICT導入では、ここが他の市場よりかなり劣っているように見えます。
それは要求をとりまとめる教育委員会の方がシステム全体を見ることの重要性を認識していないことと、この業界に関わる事業者側でその辺りの力量を持つエンジニアが少ないこと、の相乗によって具現化しているように感じています。

自分が書いているnoteでは、制度や仕組み、システム全体の設計に関わる部分が多いのは、前々からこの辺りに危機感を感じているためです。

今後も、アーキテクトに関わる部分は自分なりの意見を発信していき、それが少しでもこの分野での貢献になるよう努めていきたいと思います。
最終的には、それがネコのためになると信じています(?)。

ではまたー。3回目は早めにアウトプットしますー。

この記事が気に入ったらサポートをしてみませんか?