サイバーセキュリティへの注意喚起が続いており、その重要性が改めて見直されています。
最近では、内閣サイバーセキュリティセンターが令和4年3月1日に「サイバーセキュリティ対策の強化について」注意喚起を実施しました。
この記事では、セキュリティの確保に必要な施策や、それを適切に行うための方法を解説します。
上流工程の設計で防げる脅威が多い
システムやネットワークで発生するセキュリティ事故の対策として、構築時における「上流工程」で適切な設計をすることが有効です。
「上流工程」で適切な設計をすることで、攻撃の防止、あるいは攻撃を受けた際の被害を最小限にすることができます。また、より下流の工程となる運用フェーズにおいて構築済のシステムやネットワークを修正する場合、既存機能への影響確認などが必要となり、対応時間やコストがより多く発生します。
設計時に考慮が必要な例としては、攻撃の防止または攻撃を受けた際の被害を最小限にするためのネットワーク制限（ポート、IPアドレス等）や、アカウントごとにアクセスできる情報の制限、脆弱性のないWebアプリケーションを開発するためのコーディング規約などがあります。
脆弱性の情報に敏感になる
システムやソフトウェアの脆弱性に関する情報は、以下のサイトなどで紹介されています。
●脆弱性関連情報に関する届出状況(IPA)
●JVN(Japan Vulnerability Notes)
自社のシステムで利用しているライブラリなど、製品ごとに調べていくのは非常に手間がかかるので、このようなサイトから効率良く情報収集をすると良いでしょう。
脆弱性への攻撃に対する対策
脆弱性対策として、多層防御の効果の高さが注目されています。
多層防御とは、システムの各層にそれぞれ適した防御を設定することで、より強固なセキュリティを実現する方法です。
例えば、顧客管理データベースに対する不正アクセス対策を検討する場合、以下のように複数の制御を行います。
●データベースサーバーを外部ネットワークから直接アクセスできない箇所に配置
●DBアクセス時のID・パスワード設定
●通信経路の暗号化
●外部通信の制限
これらについても、システム設計等の上流工程において検討したい項目となります。
セキュリティの要素とレイヤーから見る注意点
セキュリティ対策には、「特定」「防御」「検知」「対応・復旧」の4つの工程があります。
| 工程 | 内容 |
|---|---|
| 特定 | セキュリティ対策の対象となるモノを定義する。 （データ、システム、サーバーなど） |
| 防御 | セキュリティの脅威が実際に発生しないように防ぐ。 |
| 検知 | セキュリティの脅威が発生した時に、それを発見する。 |
| 対応・復旧 | セキュリティの脅威が発生した時に、被害を最小限に抑える。 被害が発生している場合に、通常の状態に戻す。 |
具体的な対策箇所としては、「アプリケーション」「ミドルウェア（DB含む）」「OS」「ネットワーク」の4つのレイヤーで考えると良いでしょう。以下にそれぞれ説明します。
アプリケーションに関する注意点
アプリケーションは、外部から接続されるため、攻撃を一番受けやすいレイヤーです。
主な攻撃には、インタフェースの脆弱性を突いた、クロスサイトスクリプティング、SQLインジェクション、クロスサイトリクエストフォージェリ等があります。
対策としては、セキュアコーディングやアプリケーション診断による脆弱性チェックや、攻撃を受けても不必要なレスポンスを返したり、サービスが異常状態になったりしないような「要塞化」があります。
ミドルウェアに関する注意点
ミドルウェアは、DBサーバーやファイルサーバーの「データ」を扱うレイヤーを指します。
セキュリティパッチ適用や設定によるアクセス制御はもちろんのこと、突破された場合を想定して、データの盗聴や漏えいが発生しても、それを読めないようにする「暗号化」や不正アクセスを早期検知するための「監視設定」等を行う必要があります。
OSに関する注意点
OSにおいても、セキュリティパッチ適用、不要サービスの停止、アクセスルート制限等の「要塞化」を実施します。
システム設計や監視とは別に、OSのサポート期限の確認やリプレース計画なども留意すべきです。
ネットワークに関する注意点
ネットワークレイヤーでは、アクセスを許可する通信を、接続元IPアドレスやプロトコルで制限し、必要最小限とします。FW（ファイアウォール）などでの通常と異なる挙動の検知、遮断や、通信内の不正なプログラムを駆除するマルウエア対策等が有効です。
システムとして問題が起きそうな箇所や項目
脆弱性が発生しやすい場所として、データがやり取りされる部分、主にインターフェースが挙げられます。以下はインターフェースの注意点の例です。
クエリストリング
Webサイト間でパラメータを引き渡す際、URLに含めて使用します。キーと値いずれもブラウザのアドレス欄に表示されるため、盗聴や改ざんが発生する危険性があります。システムは盗聴されてはいけないデータをクエリストリングに含めない、改ざんされても権限外のデータアクセスや操作ができないようにする、といった対策が必要です。
クロスサイトスクリプティングやSQLインジェクションは、この脆弱性を悪用して実現します。
RMI
コンピュータ間の通信を行うためのインターフェース。初期設定のまま使用するとデータが暗号化されていない状態で通信されるため、暗号化の対応が必要です。
セキュリティ設計を行う上で大切なこと
セキュリティを考慮したシステム構築に関して留意すべき事項として「セキュリティ・レビュー」「重要情報のレビュー」「契約に基づく設計」「特権処理の局所」があります。
必ず実施すべきセキュリティ・レビュー
セキュリティ脆弱性となりそうな問題を事前に発見し、排除につとめるためのセキュリティ・レビューは重要です。
レビューにあたっては、システム設計者とは別の人間に担当してもらうなど、属人的にならないような工夫も必要です。外部ベンダーにレビューを依頼する、という選択肢もあります。
重要情報のレビュー
システムで取り扱う重要なデータが安全に扱われる設計になっているかをレビューします。
どのデータが「重要データ」なのかを定義し、それに対して発生、入力、伝送、保管、呼び出し、変更、複製、印刷、消去といった工程において、不用意な露出がないか、改ざんの機会がないか、内容が損なわれる可能性がないかをチェックします。
「契約に基づく設計」を取り入れる
「契約にもとづく設計」（Design by Contract）という設計思想があります。これは、バートランド・メイヤー（Bertrand Meyer）が提唱したプログラム設計に関する考え方で、事前条件を満たした状態でプログラムを呼び出した場合、事後条件を満たす状態でプログラムを実行する、という内容です。
この考え方はセキュリティ対策においても有効です。例えばパラメータ「ファイル名」をプログラムに渡すときに、「パスを含んだファイル名」を指定すると、任意のフォルダにあるファイルを不正に取得できてしまいます。この場合、事前条件として「パラメータ「ファイル名」にはパス（￥と／）を含めない」というルールを提示することで、脆弱性を回避することができます。
特権処理の局所化
脆弱性を突かれて実際に攻撃を受けてしまった場合でも、処理ごとに権限を細かく設定することで、被害を最小限に抑える対策が可能です。
例えばDBに対する権限を一律フルコントロールにするのではなく、検索・閲覧機能には参照権限のみ、登録機能にはフルコントロール権限、というような使い分けをすると、検索・閲覧機能で脆弱性があっても、データの改ざんや破壊は回避できます。
ここまで説明した通り、セキュリティ対策は「上流工程」で適切な設計をすることが有効です。
まとめ「セキュリティ設計は上流工程に留意し、IPAのガイドラインなどを参考に」
「上流工程」で適切な設計をすることで、攻撃の防止、あるいは攻撃を受けた際の被害を最小限にすることができます。
セキュリティ設定を自社で行う場合、「ISO/IEC 27001」や「PCI DSS」などのガイドラインを参考にすると良いでしょう。
