ガバクラ利用に追加された非機能要件「媒体での外部保管及びネットワーク経由での遠隔バックアップ」

ガバメントクラウドなど^*1の利用に関する「地方公共団体情報システム非機能要件の標準」^*2に、媒体での外部保管及びネットワーク経由での遠隔バックアップが追加されたと話題になっていた^*3。

既にこれまでの（もしくは、そうだと思っていた^*4）要件に沿って開発中なので、このタイミングで要件を追加する必要があったのか、追加コストや具体的なソリューションをどうすれば良いか、困惑を招いている。

デジタル庁の文書ではランサムウェア対策を謳っており、確かにシステムが完全に乗っ取られた後のリカバリーを考えると、上の非機能要件は有用だ。ランサムウェアによって暗号化されたデータの復元は困難だし、そもそも復元可能になっているかも分からない。また、システムから制御できる位置にあるデータは、バックアップを含めてリスクがある。

1. ランサムウェアに侵入される可能性

ただし、地方自治体の基幹業務においてランサムウェアが入り込む余地はほとんど無い。

• ランサムウェアの侵入経路としては、怪しいメールの添付ファイルやURLをクリックしたら云々と言うエンドユーザーの油断や不注意を突くものが多いが、ファイルサーバーではなく基幹システムをこれで攻略するのは困難だ。エンドユーザーはアプリケーションを通してしか基幹システムを操作できない。
• サーバーソフトウェアやアプリケーションのセキュリティーホールを突くタイプの攻撃も、基幹業務において受ける可能性は低い。ガバメントクラウドに関係なく、自治体のセキュリティー対策は、とくに基幹業務に関してしっかりしている。ほぼ完全な閉鎖系で、外部攻撃から攻撃するのは困難だし、侵入検知システムも置かれている。

既知のセキュリティーホールのあるサーバーソフトウェアを使っていて、かつネットワーク設定に重大な誤りがあれば何か起きるかも知れないが…と言った程度だ。

2. 議論の非機能要件以外の対策

また、議論の非機能要件以外の対策もある。サーバーソフトウェアとアプリケーションを実行するアカウントと、バックアップを管理するアカウントを分けておけば、前者が攻略されても後者の管理するデータは破壊や改竄はされない。なお、OSの管理範囲でやる場合はOS管理者権限の奪取まで考え強制アクセス制御かコンテナ技術の併用が推奨されるが、マネージドサービスを使う場合はクラウドのアカウントを分ければ^*5隔離できる。

3. その他の可能性を考えると、悪くない対策

遠隔地にバックアップをとり、そこでテープドライブ等に保存すること自体は、悪い対策ではない。マルウェア対策となると同時に、それ以外の問題への対策にもなる。

悪意のある作業員によるシステム破壊は実際に過去にあった^*6。外資系クラウド事業者が政治的にサービスを停止するリスクも実際のところはある。トランプ大統領がICCへの制裁を命じ、ICCのKarim Khan主任検察官の銀行口座も閉鎖され、Microsoftのサービスのメールアカウントが凍結されたことがあった。米系サービスはもはや安全とは言えない。

やるべきか否かというと、やるべき。追加の工数も（データ量が一定以下であれば）そうは多くない。つまり、

• レガシーなクラウドの場合は、RDBのアーカイブログを含めたファイル群をオンプレミスのサーバーにミラーリングし（e.g rsync）
• モダンなクラウドの場合は、オブジェクトストレージ（e.g. AWS S3）にデータベースのスナップショットと画像ファイルなどのデータを格納し、オブジェクトストレージとオンプレミスのサーバーのファイルシステムのミラーリングをし（e.g. aws s3 sync）

テープドライブに保存すればよい。ネットワーク経由での遠隔バックアップ及び媒体での外部保管と順番が逆になるが、実現できる。差分バックアップなので、ネットワーク費用の増加も言うほどではない。ただし、オンプレミスのバックアップサーバーのデータや外部保管先のメディアが強奪されないように、対策をとる必要がある^*7ことには注意しよう。

開発進行中に要件が増えるとストレスなので、来年度以降の要件にした方が良かったとは思うが。なお、デジタル庁が毛嫌いしているバッチ処理が増えることになる。

*1「「ガバメントクラウド・パブリッククラウド・独自クラウド（自治体クラウド）上で稼働する標準準拠システム」向けの非機能要件標準」だと指摘を受けたので、表現を修正した。

*2「地方公共団体情報システム非機能要件の標準【第1.1版】」「地方公共団体情報システムにおける標準化にかかる共通基準に関する検討会（第四回）」の項番A.3.2.2に関する記述が問題になっている。

*3ネットワーク経由での遠隔バックアップがあればメディアでの保存は不要と思われていたが、第1.2版案で両方の実施が明確に原則になった。「各開発ベンダ・市町村が調達を行う際に使用する非機能要件のレベル」が2だと書かれていて、[-]で選択レベルを下げる場合の条件を記している。いずれかの運用で許容できる場合は片方で済むとあるが、備考に「近年、ランサムウェアによるセキュリティインシデントが多発していることに鑑みると、リモートバックアップに加えてオフラインバックアップを取得することが望ましい」と圧がある。

*4第1.1版の記述には「…のみ」と「…を含む」があるので、レベル1（媒体），レベル2（媒体と遠隔）と解釈すべきだと言うような指摘があった。「…を含む（媒体による外部保管）」なのか「…を含む（外部保管）」なのかは悩ましいところではある。

項番A.3.2.2は「地震、水害、テロ、火災などの大規模災害発生により被災した場合に備え、データ・プログラムを運用サイトと別の場所へ保管するための方法」である。「同時被災の恐れがない遠隔地」へのネットワーク経由のバックアップがあるときに、さらに媒体に保存しておくことで、さらに大規模災害への備えが充実するとは考えづらい。

*5AWS Backupで別のAWSアカウントのRDSをバックアップ実行と管理 #AWSBackup - Qiita

*6関連記事：レイオフされたエンジニアが元勤務先のサーバーを消去

*7クラウド事業者の提供するキーマネージャーを使った暗号化をかけておくと、クラウド事業者のサービス停止に対してどうにもならなくなる。