権限制御・システム監視について | システム導入検討のエッセンス（１０）

イントロダクション

RFI・RFPについての第１０回、非機能要件詳細についての第７回目になります。
とうとう本テーマも１０回目になりました。
RFI・RFPという本来のテーマを忘れそうになりますが、この話の主旨は「システム調達でRFIやRFPを書くときに、機能要件ばかりに目が行きがちだけど、非機能要件もちゃんと考えましょう。ところで非機能要件って何？」です。

本テーマ第３回目でお話したように、非機能要件は主に５つの要素で構成されます。

１．可用性：運用時間、バックアップ、耐障害性、SLA
２．性能・拡張性：レスポンスや処理時間、スケールアップ・スケールイン
３．移行性：データ移行、運用移行、研修計画
４．セキュリティ：権限制御、システム監視、脆弱性に対する対策
５．システム環境・エコ：耐震／免震、重量、温度、騒音、CO２排出量、消費電力

前回まで上記の１～３についてお話してきました。
今回は４のセキュリティについてのお話です。

セキュリティと一口に言っても色んな要素があります。
システム単独で守れるものもあれば、周辺環境も含めた対策が必要なものもあります。
一つ一つに突っ込んだ話をしていたら、それだけで１サイトできそうな（他もそうなのですが）テーマなので、「気を付けるべきこと」のレベルでお話していきたいと思います。

権限制御について

誰に何を使わせるのか＝誰に何を見せてはいけないのか

システムの規模によって要件は変わるかもしれませんが、運用管理を自社で行う場合、ユーザー管理と権限制御はほぼ外せない要件になります。

他の人や他の所属が登録した内容が見えてもいい人、見えてはいけない人、マスタ情報が操作できる人、できない人を管理することは、セキュリティ確保の基本です。
どんなに大雑把な分け方をしたとしても、一般ユーザーと管理者ユーザーの区分けくらいは必要になります。システム規模にもよりますが、一般ユーザー、管理職ユーザー、部門レベルの管理者、システム全体の管理者ぐらいは必要ではないでしょうか。

現行運用のヒアリングで現在の業務フローを確認する際には、必ず「登場人物」を意識しましょう。登場人物が何ができないといけない人なのか、その人と別の人は同じことができて良いのか駄目なのか等をまとめることで、必要な権限を洗い出すことになります。

情シスを悩ませる権限設定

「権限を設定することができる」くらいの基本的な機能は大体のシステムで持っているでしょう。しかしその設定の考え方によって、情シスの苦労は大きく変わります。

アクセス制御の権限の考え方をベースすると、大きく３つに分類できます。
運用実態に合わせて必要なレベル感を考えるようにしましょう。

任意アクセス制御：オブジェクト（機能やファイル）毎にアクセス権を設定する方法

例えば、画面αはAさん、Bさん、Cさんは操作可能、Dさんは閲覧可能、Eさんは操作不可、
画面βは…のように、それぞれに利用可能な人を設定していきます。
権限設定の柔軟性が高い一方で、１機能ずつ／１人ずつの設定が必要になるので、例えば人事異動や昇給昇格による権限変更はとても面倒なことになります。

強制アクセス制御：オブジェクトとサブジェクト（ユーザーやアプリケーション）にセキュリティ・レベルを設定し、双方のレベルを比較してアクセス権を設定する方法

例えば画面αのセキュリティレベルは２とします。
ユーザーのセキュリティレベルと操作可否は以下の通りです。

Aさん：レベル１→操作不可
Bさん：レベル２→閲覧可能
Cさん：レベル３→操作可能

個々の設定はセキュリティレベルのみになるのでメンテナンスは容易になりますが、例外的な設定（例：Dさんはレベル２だが、画面αだけは操作まで行いたい）が行いにくいのが難点です。

ロールベースアクセス制御：役割に対し。て権限を設定し、ユーザーには役割を付与する方法

わかりやすいのは役割＝役職とする場合です。
画面αに対して役職ごとの操作可否は以下の通りとします。

担当→操作不可
係長→閲覧可能
課長→操作可能

こうすることで、ユーザーに対しては役職を設定するだけで権限制御が可能になります。
また、例外的な権限（例：係長（操作可能））を設定することも可能です。
必要になる役割が何か、同じ役割の人は本当に同じ権限で良いのかをしっかり検討しておく必要があります。

環境を含めた権限制御が必要な場合

取り扱う情報によっては高度なセキュリティを確保しなければいけない場合があります。

例えば秘匿性の高い個人情報を扱うシステムの場合、インターネットから接続できないネットワークに配置したり、端末レベルで操作可否を制御したり、部外者が入れないセキュリティゾーンの端末からしか接続できないようにする等の対策が必要な場合があります。

こうなるとネットワークセグメントやオフィスレイアウト、セキュリティゾーンの確保等の環境面での要件が必要になり、SIベンダーではなくユーザーが確保しなければいけない場合もあります。

システム監視

「ログが出せます」→何についての、いつまでのログなのか

システム監視といえばログイン情報や操作ログ等のログ管理が一般的です。
ただログさえ出しておけばいいかというとそういうわけでもないです。

何のログが出せるのか、出力される情報は何なのかというログの中身の問題以外にも、どの期間のログを保管できるのか、ログの保管領域の容量は十分かといった点も考慮する必要があります。

GDPRの72時間ルール

ログについて「問題が起こった時に後から調査できればいい」くらいに思っていてよかったのは一昔前までの話です。

以前当ブログでも少し触れたGDPR（EU一般データ保護規則）では、個人データが漏えいした場合の規定を以下のように定めています。

「個人データの侵害が判明した場合は72時間以内に関係当局へ通知することを義務付ける。」

これは「個人情報が漏えいしているかもしれない」ということがわかった時点を開始時刻として、そこから３日以内にいつ、何が、どの程度流出したのかを明らかにして通知しなければいけないのです。

果たしてそのシステムログは３日で発生した現象を全て明らかにできるでしょうか。

GDPRはEU域内の人を対象にした規則とはいえ、影響のある企業もあるでしょうし、今後同基準の規則が日本や他の地域で施工される可能性もあります。
容易に解析可能なログであるか、あるいはログの解析を含めた保守サービスが提供されることを要件に入れるべきか検討する必要があります。

アラートを飛ばせばいいってものでもない

セキュリティインシデントの発生を検知する方法としてシステムからのアラートがあります。アラートの手段としては、画面にメッセージを表示したり、アラートメールを送信したりする方法があります。

ただしこのアラートも適切な条件で発生させないと全く役に立ちません。
インシデントが発生しているのにアラートが飛ばないのは論外ですが、本来アラートが出なくても良いような事象までインシデントと捉えてアラートを飛ばしてくる場合があります。
これをやられると、最初のうちは問題が発生したのではないかと都度てんやわんやになり手を取られますし、継続してくると「ああ、どうせまたあれでしょ」と思うようになり、本当に検知しなければいけないアラートまで無視されることになります。

アラートの要否と共に、どのような方法でアラートが通知されるのか、アラートが発生する条件は何かを検討するようにしましょう。