zd6ir7

プロジェクト背景
SOX法に基づく監査法人からの以下の対応要請に伴い、筆者担当システムに対して情報セキュリティ強化が求められたためシステム対応を実施したもの。

• OSとDBMS共通
  パスワード変更、パスワードポリシー設定(※)、不要IDの無効化または削除
  (※)文字長8文字以上、文字記号数字の組み合わせ、100日以内の変更運用等
• DBMS個別
  アクセス元制限

筆者の立ち位置
プロジェクトマネージャ兼アーキテクト兼情報セキュリティ分野の有識者として参加

対応内容
筆者担当の3システムのOSとDBMSに対して以下を実施。いずれもOSはAIXで、DBMSはOracle。ただし1システムだけOracleは11gR1を使用。それ以外は12cR1。

• AIX OSとOracle IDのパスワード変更
• AIX OSのOracle DBの設定変更によるパスワードポリシー設定
• Oracle設定ファイルでアクセス元IPセグメントを指定することによる指定外IPからのアクセスを遮断

プロジェクトで発生した課題と解決策
以下の課題が発生するも解決し計画通りのサービスインを実現。

• SSH鍵認証で接続している既存システムへの影響
  OS IDのパスワード変更による影響が懸念されたものの、鍵認証であり影響はないことを確認済み。

• Oracle11gR1の機能制約とシステム制約
  Oracle設定ファイルでアクセス元IPセグメントを指定しようとしたが、1システムだけOracle11gR1の機能制約でセグメント単位ではなくIPアドレス単位で指定する必要があった。またそのシステムは世界中からアクセスされアクセス元IPセグメントは300近くあった。単純計算で7万個以上のIPアドレスを指定する必要があり、誤設定に伴う予期せぬ誤作動やメンテナンス性を損なうためアクセス元IP指定に伴うアクセス制御は断念。
  監査法人と協議し、Oracle監査ログを取得し定期的に不正アクセス・操作の有無をチェックする運用を設けることで決着。その際、監査ログからアクセス元IP、ID、日時、操作内容を抽出して本番環境からダウンロードするジョブスクリプトを開発してリリースした。

• 固定パスワードでのOracleアクセス
  別のシステムではOracle DBへの接続に関する問題が発生した。そのシステムのDBへアクセスするIDは全て固定パスワードになっていた。定期的なパスワード変更運用に乗せようと考えるも、IDの多くは利用部門の反対で実現は不可。ただこのシステムでは、例えばID「AAA」であればXサーバからしか来ない、ID「BBB」であればYサーバからしか来ないというように、IDとアクセス元セグメントが紐づいている特徴があった。従って、以下の機能を持つスクリプトを開発してリリースした。

Oracle監査ログを一定間隔で監視。

設定ファイル上に「ID＝アクセス元セグメント」という形で設定、例えば「AAA=192.168.1.0」であれば192.168.1.0以外のセグメントからAAAのIDを使ってアクセスした場合はアラートを出力。

• 欧州からの固定パスワードのFTPアクセス
  更に別のシステムではFTP接続の問題が発生した。欧州のサーバがそのシステムのIDを使ってFTP getをしているわけだが、そのパスワードは固定のままだった。これを機に、SSH化またはFTPパスワードの定期的な変更運用を欧州側に提案したが、先方は予算、人員等の都合から対応は不可との回答。粘り強く協議するも難航。以下の対応を行うことで決着。

当該FTP IDの「ログイン可」設定を「不可」に変更することで当該IDを使ったOSログインを防止。FTPへの影響はないことは確認済み。

FTPは欧州のサーバからしか来ないため(正確にはネットワークで絞っているため)、ログを定期監視し欧州以外のサーバからFTPでのアクセスがあった場合にアラートを出すスクリプトを開発してリリースした。

プロジェクト背景
東南アジア政府当局の法規制により、以下が求められたため、筆者所属会社の情報系システムに対しても対応を行った。
●対象は、東南アジア顧客にITサービスを提供しているシステム
●マシン本体がどこに置かれているかに関係なし
●データベースのデータは暗号化。かつ復号化/再暗号化に必要な鍵は当該システムとは別サーバに配置

筆者の立ち位置
プロジェクトマネージャとして参加。

システムの対応
●Oracle Database 11gR1の暗号化機能を使って表領域を暗号化
●別マシンに暗号化/復号化用の鍵を配置。Lunaメモリからディスクへの書き込みに際して利用。
●データベースと鍵が置かれたサーバ間の連携はLunaHSMを使用。

プロジェクトで発生した課題と解決策
以下課題が発生するも、期限内までに当局要件を充足した対応を実現。

• オンラインレスポンスの劣化
  復号化と再暗号化処理が走るため、オンラインレスポンスが劣化。そのため物理メモリサイズを増やし1日の業務開始前にデータベースの内容をメモリにキャッシュさせることでオンラインレスポンスを確保。そして1日の業務終了後にインスタンス再起動させることでキャッシュ内の情報をディスクに反映。

• 原因不明の書き込み処理の失敗
  更新処理が発生する際、REDOログ(更新差分ログ)にその情報が書き込まれる。書き込みにより当該ログのディスク容量が足りなくなるとスイッチが発生し別のディスクに書き込むが、その際上述のキャッシュ内の情報をデータベースに書き込む。その書き込み処理の中で鍵をリモートサーバから取得する箇所で失敗。
  オンライン中に上記エラーが発生すると業務に致命的な影響を与える。原因解析のため、ログから調査したが突き止められず。製品サポートにも問い合わせるも、11gR1はサポート切れであり調査不可との回答。
  オンライン中はスイッチさせないようREDOログのサイズを大幅に拡大することで問題を回避。

• 原因不明のスタンバイデータベースへの更新処理失敗
  当該システムにはスタンバイデータベースがあり、通常業務提供しているプライマリデータベースの更新差分ログを1日の業務終了後にスタンバイデータベースに適用させることで、データ同期をとっている。
  だが、本プロジェクトでの対応により、スタンバイデータベースへのアーカイブログ適用が失敗。
  こちらも原因を解析しようとしたがサポート切れで解析できず。検証を続けたところ、インスタンス再起動して10分以上経過してアーカイブログ適用したところ成功することが判明。この処理をJP1ジョブに組み込むことにより、プライマリ-スタンバイ間のデータ同期を実現。

プロジェクト背景
当時、SOAP Webサービスを使ったオンライン連携の開発が盛んであり、その開発効率化が求められていた。その中で、同じくSOAP Webサービスを使う大規模プロジェクトにおいて以下要求が挙がったためツールを開発、提供した。
●Excelベースの所定フォーマットに、公開したいWebサービスの情報を記載。
●同ExcelファイルをからJavaのWebサービスのクラスファイル群、WSDLファイルを生成。

筆者の立ち位置
プロジェクトマネージャ兼プログラマーとして参加

対応内容
①Excelベースの所定フォーマットに、名前空間、Webサービス名、入力/出力項目等を定義できるよう設計。同ファイルはApache POIで読み取り。
②①のファイルとは別にApache Velocityをベースとしたテンプレートファイルを用意。クラス詳細情報を定義できるよう設計。
③WSDL作成にアプリケーションサーバ製品付属のwsgenコマンドを利用。
④①～③のファイル、コンパイル用の関連ライブラリを予め配置しておき、Windowsバッチファイルをたたくことで、Webサービス関連クラスのJavaソースファイル、クラスファイル、WSDLファイルを生成。

プロジェクトで発生した課題と解決策

• 非常に短い開発期間
  難易度、開発ボリューム、要員状況から半年以上かかる予定であったが、当時の社内事情から要件定義からツール提供まで4か月に満たない期間での対応をせざるを得なかった。複数プロジェクトが並行して走っている状況であったが、相手先プロジェクトと調整して相対的に優先度の低い開発を行っていたPOI経験のあるエンジニアを本開発に回して要員確保。
  また、POIで読み取る部分、VelocityからJavaソースファイル、クラスファイルを生成する部分、wsgenによりWSDLファイルを生成する部分に分割。それぞれにエンジニア(筆者を含む)を割り当て。結果、予定どおりにツール提供を実現。

• 複数のアプリケーションサーバへの対応
  開発当時はSOAP WebサービスがWebSphere Application Serverを前提としていたが、開発途中でglassfish、Cosminexusにも対応したい要望が挙がった。wsgenでWSDLファイルを生成する際、アプリケーションサーバによってオプションが異なってくる。そのため設定ファイルのパラメータをコントロールすることにより、それぞれのアプリケーションサーバに対応。