Secure Cube/Access Check

では、実際に「アクセス管理」を実施する場合の問題点を例題で考えてみよう。  

例えば、開発側から本番環境にアクセスするような業務では、新たに「アクセス管理」を実施しようとすると次のような障害要因が浮かび上がってくる。

　　・サーバのID、パスワードが共有されている
　　・サーバごとにID、パスワードを再設定するのは大変な労力が必要
　　・各サーバのログは記録されているが統合的に管理できない
　　・端末とユーザーの紐付けが行われていない
　　・クライアント端末にエージェントを導入するのは困難

このような障害要因を1つひとつ解決していくことは非常に困難であり、費用も、手間も、時間も掛かってしまう。

そこで、今、内部統制を実現するための「アクセス管理」を、具体的かつ効率的に解決するソリューションが求められているのである。  

NRIセキュアテクノロジーズが提供する「Secure Cube/Access Check」は、サーバへのアクセスを制御・管理することで、セキュリティの強化と「IT全般統制」の強化を一気に解決するソリューションとして注目されている。  

それでは、引き続き、「Secure Cube/Access Check」の機能を見ながら、このような障害要因をどうクリアしていけばいいのか考えてみよう。

特定の環境に依存せず円滑な導入・運用が可能なことは、既存のシステムへ新たに「アクセス管理」機能を追加する場合、非常に重要なポイントとなる。  

「Secure Cube/Access Check」は、既存の端末や既存のサーバに対して、エージェントなどのソフトウェアをインストールする必要がない。端末側のOSやソフトウェアにも依存せず運用が可能となっているので、既に本番環境が動いている環境でも導入が容易だ。  

また、フェイルオーバーを含む運用・監視に関するさまざまな機能を内包しているので、他の運用管理ソフトを導入しなくても、「Secure Cube/Access Check」のみで円滑に運用業務を行うことができる。

「Secure Cube/Access Check」は、Telnet、FTP、HTTPといった主要な通信プロトコルに対応している。そのため、ネットワークのセキュリティ境界にAccess Checkサーバを設置するだけで、簡単に強力な「アクセス管理」機能を導入することができるようになっている。  

例題で取り上げた、開発環境セグメントから本番環境サーバへの「アクセス管理」を行う際でも、システム運用サイドとシステム開発サイド、両方のアクセスの門番となり、障害対応、メンテナンス等で開発環境から本番環境へアクセスする際に、開発サイドが勝手にシステム設定を変更してしまったり、必要のないデータにアクセスしてしまったりするような事態を防ぐことができる。  

また、「Secure Cube/Access Check」は、個人情報や営業秘密を取り扱うサーバのシステム運用管理などにも有効なソリューションである。

アクセス統制を実現する「アクセス申請/承認機能」を実装しているのも「Secure Cube/Access Check」の大きな特長だ。
 
ユーザーは、Access　Checkの管理画面にて、アクセスの目的、システム名、アクセス時間などを記入してアクセスを申請。システム管理者が、申請内容を確認して承認／却下することができる。そのため、申請された内容をもとに柔軟にユーザーのアクセスをコントロールできるようになっている。

「Secure Cube/Access Check」では、アクセス日時やIPアドレスといった「サマリーログ」と、送受信されたデータの「全文ログ」を取得することが可能となっている。

さらに、検索条件を入力し、該当するアクセスログだけをダウンロードすることも可能だ。  
そのため、不正アクセスの追跡や抑止効果が期待できる一方、冒頭でも述べたように、監査法人に「アクセス管理」が厳密に行われている資料として、アクセスログを提示することも簡単にできる。

加えて監査法人では、「アクセス管理」がいい加減だと、財務報告が改ざんされてしまったり、プログラムが書き換えられてしまったりする可能性が高いと判断する場合があるという。