１．運用自動化導入は茨の道

これまで、運用担当者が社内で提案する運用自動化の目論見が、脆くも崩れ去る場面を見ることが多々ありました。
その理由は、主に管理者が現場の業務や負荷を十分に把握しきれておらず、自動化の必要性を認識していなかったことが一因と考えられます。
現場の運用担当者は、日々の運用作業とユーザーニーズの対応に追われてバタバタ状態なのに加え、突然の障害対応などで業務が逼迫するため、自動化ツール導入により少しでも負荷を減らしたい、多くの要望に応えたいと考えています。しかし、担当者の日々の作業がブラックボックス化しがちのため、管理者としては費用対効果の視点から、現状維持を強いざるを得ないというパターンでした。

一方、管理者が展示会などで運用自動化ツールを見て、これはイケルと思い、運用担当者に導入検討を促すものの、現場は現場なりに自前で作成したツールや手持ちのShellスクリプトに固執し、現状維持を望むという反対のパターンもあることにはありました。
両者が手を組んで自動化に突き進むという構図は、これまでは少なかったのです。
運用自動化は、強力なリーダーシップを持つ管理者が運用担当者の業務を正しく理解し、協調して進めていかないと、ストップしてしまう可能性が高かったのです。

２．予算化するには

しかし、そのような状況は、あるマジックワードで変わりつつあります。

それは『DX：デジタル・トランスフォーメーション』と『サイバーセキュリティ対策の強化』です。

DXは多くの企業で、年次計画や中期経営計画のテーマとして取り上げられています。
このため、このテーマは予算として通りやすいものです。単に事務作業や製造工程にとどまらずシステム運用にも当てはまります。
『2025年には、IT投資の90％が運用維持コストになってしまいかねない』、という経産省のレポート（※1）での警鐘にあるように、システム運用においてコスト削減や運用方法の改善が強く求められてもいます。
システム運用には「繰り返し」「手間がかかる」作業が多いため、DXの格好のテーマになり得るのです。是非この機会を活用すべきです。
DXを最大限活用し、来年度の予算に組み込むのは、まさに「今」がチャンスです。

また、内閣サイバーセキュリティセンター（NISC）では、サプライチェーン・リスク等の新たな脅威を先取りした対応を推進し、組織の壁を越えたサプライチェーン全体でセキュリティを向上するための取り組みを進めています。

NISCは、経営層、CISO、戦略マネジメント層、システム担当等、組織全体での取り組みとなるよう、組織統治の一部としてサイバーセキュリティを組み入れるよう啓蒙していますが、日本では海外に比べ経営トップの関与は進んでいません。

しかし、今後は海外に倣って、経営トップを巻き込んだ動きが拡がることになるでしょう。日本だけ対策が遅れていると、世界から村八分にされかねません。

このため、経営トップからの指示でサーバーのセキュリティ対策強化が下達され、構成情報の日次収集、定期的なバックアップやログの収集、パッチのタイムリーな適用等、現場の作業は増えることにつながるでしょう。

NISCでは2023年の7月4日に『重要インフラのサイバーセキュリティ部門におけるリスクマネジメント等手引書』をリリースし、具体的な運用管理の内容を提示しています。

（※1）「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～」より。DXの実現には、既存システムの問題を解決するために業務自体の見直しが求められるが、これが実現できない場合には、2025年以降、最大12兆円/年（現在の約3倍）の経済損失が生じる可能性を示唆している

３．稟議を上げる

具体的に稟議を上げるためにはどのような点を訴求すべきなのでしょうか。
運用自動化の企画からはじめ、実際に導入、運用を行っている先進ユーザーのアドバイスをまとめると、次の３点が参考になります。

• ポイント１：運用自動化は単なる効率化ではなく、システム運用業務のDXと捉え、組織や体制、ビジネスモデルの変革、サービスの向上を目的とする。
• ポイント２：自動化することが目的ではなく、導入後、自動化による改善を継続的に進めていくことで効率化のみならず、標準化、ひいてはサービスの向上に繋げることを挙げる。このため、運用自動化ツールは、多くの人が利用でき、使いやすいものを選択することが必要で、継続的な改善と知恵を出し合えるようなプラットフォームであるべき。
• ポイント３：運用自動化でのコスト削減効果は、現状との比較だけでなく、本来あるべき姿（脆弱性対策や最新構成情報の収集など本来やらなければならないこと）を含めて比較する。

運用担当者が日々「繰り返し」「手間がかかる」作業だと感じているが、非常に重要な３つの作業について、具体的な作業内容とねらいを図１にまとめてみました。
構成情報の管理では、最新の情報を毎日「繰り返し」収集することで可視化し、脆弱性問題の対策やコンプライアンス対策、保守切れ対策などに利用可能です。
スクリプトジョブの作成では、パッチの適用や設定の変更など、「手間がかかる」作業を自動化することが可能になり、オペレーションミスの撲滅や作業効率の向上が実現できます。
弊社の運用自動化ツールPOLESTAR Automationでは、これらの作業を簡単に実現できるしくみが用意されています。

４．属人化しない運用自動化プラットフォーム

運用自動化ツールの導入に当たってハードルが高いのは、自動化のためのスクリプトジョブの開発です。
スクリプトを書くためのPower ShellやVB Script, Pythonなどの言語を習得しなくてはならないということが重荷になっていました。
図２は、運用自動化ツールPOLESTAR Automationにおける、ジョブ作成を簡単に行うためのウィザード（フレームワーク）です。目的別に9種類のウィザードがあり、対話式の画面でマウスを使いながら、ジョブを短時間で作成できます。もちろん、コアとなるスクリプトは書かなければなりませんが、対象サーバーや実施スケジュール、メール通知など、大部分の設定はマウスだけで済みます。
ファイル配布ジョブの場合はマウスだけでの設定が可能で、１分もかからずにジョブが作成できるという簡単さです。
1,100種類以上のサンプルジョブが無償で提供されているため、すぐに自動化を開始できますし、その内容を参考にすれば、担当者自身でも簡単なジョブであれば短期間で作成ができるようになります。
このように、多くの人がプラットフォームとしての運用自動化ツールが使え、関われるようになることで、運用作業の改革や改善に取り組むことができるようになるのです。

５．小さく始めて大きく育てる

今回ご紹介しているPOLESTAR Automationは、商用の運用自動化ツールです。
商用というと、無償のOSSツールと比べて高価というイメージを持たれるかもしれません。
しかし、企業で利用する場合はソフトウェア・サポートを購入することが多く、全くの無償のまま利用することは少ないようです。
POLESTAR Automationは、買い取りでのライセンス販売と年間利用料金のサブスクリプション販売があります。（参考価格）
サブスクリプションの場合は最低10ノード(*1)からで10ノード単位での購入が可能です。また、サブスクリプションにはソフトウェア・サポートとバージョンアップの権利がついています。
価格は、サーバー１ノード　\12,000/年(*2)（税別）で、10ノードでは\120,000/年(*3)（税別）になります。

まずは、20ノード、30ノードからご利用いただき、POLESTAR Automationで運用DXを始めてみませんか？
段階的に自動化を進めることで、「自動化のお作法」に慣れ、「自動化のカン」を養うのが、成功の秘訣であると、先進ユーザーもアドバイスしています。
また、弊社では運用DXを早期に実現するための「ITインフラ運用DXまるっと構築支援サービス」もご用意しておりますので、是非ご利用ください。

*1　サーバーの場合、管理対象となるOSの数量
*2　オプションは含みません
*3　初年度は2年分のご契約をお願いしています。3年目からは単年の契約が可能です。



ソフトウェアエンジニアが、システム運用も含めて設計するという意味合いで、システム管理者の役割も担うというのがサイト・リライアビリティ・エンジニアリング（SRE）。サービスの「リリース」と「安定稼働」という重要な業務を、品質と可用性を担保しつつ実現しようとする考え方である。

SREはGoogleが発祥で（SREとは？サイトリライアビリティエンジニアリングを実現するためのキモはトイル対策）、GoogleのSREチームでは、いわゆる「トイル（労苦）」に費やされる時間を勤務時間の 50% 未満にすることを目指しているという。つまり、手作業や繰り返し作業が多ければ多いほど、SREチームが運用に振り向けられる作業時間は限られてくる。

このため、ソフトウェア・エンジニアリングを最大限活用することで、手作業や繰り返し行われる作業「トイル」を減らし、そしてソフトウェアによるコントロールを通じ、可能な限り自動化を駆使しようとしている。

自動化を実現するツールの中でも、スクリプトを対象デバイスに実行するためのジョブスケジューラ/構成管理ツールが、SREチームのトイル削減において、最も大きな役割を担う。

自動化スクリプト作成にあたって非常に重要なのが、「OPALLS（オパール）」という概念である。
ここでは、システム運用の自動化の状況と、ジョブスケジューラ/構成管理ツールで実行される自動化スクリプトに必要な機能を、「OPALLS（オパール）」という概念でまとめてみたい。

自動化ツールの構成

まずは、自動化ツールの現状を俯瞰してみたい。
システム運用の現場では、一般的にサーバーやネットワーク機器、アプリケーションなどの状況を常時監視する「監視ツール」。システムを構成するハードウェアやソフトウェアの構成情報を収集するとともに、スクリプトで返り値の取得や設定の変更を行う「ジョブスケジューラ/構成管理ツール」。そして、障害発生時のインシデント/チケットの情報を登録し、進捗を管理する「ITSM　（IT Service Management）ツール」がある。これらがAPIで連携され、自動変更や修正、情報の収集・登録などを有機的に行えるようになっている事例も増えている。

これにワークフローや、AIを装備し予測が可能になるオペレーション分析・管理ツールも新たに加えられるようになった。

このようなツールの活用は、SREの推進においては不可欠である。特に、スクリプトによる自動化を行うジョブスケジューラ/構成管理ツールの効果的な活用が鍵を握る。

スクリプト実行に重要な「OPALLS（オパール）」とは

OPALLSはスクリプトの自動化を支援する概念で、O（対象デバイス設定）、P（前後処理）、A（完了通知/アラート）、L（ライブラリ）、L（ログ）、S（スケジュール設定）からなる。

実際に自動化スクリプトを作成する順序で説明してみよう。

１．対象デバイス設定（O）
スクリプトを送り込む対象デバイス（サーバー、ネットワーク機器）を設定するが、ドラッグ＆ドロップ等UIで個々のデバイスやグループを簡単に選択できることで、簡単かつ視覚的に設定を行う。

２．ライブラリ（L）
よく利用するファイルやスクリプトを登録しておくことで簡単に呼び出すことができれば、繰り返し作業を排除し、効率化につなげることができる。

３．前後処理（P）
ファイル配布前や配布後など、実行の前後にスクリプトを実行し一連の作業を行えることで、パッチ適用やファイルの導入を１つのタスクとして設定・管理できるようになる。

４．スケジュール設定（S）
スクリプトを実行する日時や、毎週や毎月など周期的な実行をカレンダーや時刻テーブルなどで簡単に設定できることで、作業の効率化が図れる。

５．ログ（L）
スクリプトを実行した結果をダッシュボードに表示し、CSV等で出力できることで結果の保存が可能になる。ISMS等のエビデンスにも利用できる。

６．完了通知/アラート（A）
スクリプト実行後に実行状況をメールやSNSで通知することで、スクリプトの実行結果をタイムリーに入手できる。

OPALLSをウィザード画面で実現したPOLESRAR Automation

システム運用自動化ツールのPOLESTAR Automationは、OPALLSの機能をウィザード画面で実現し、作業手順の大半をマウスだけで実行可能としている。
また、点検や差分チェック、ファイル配布など目的別のウィザードがあるため、必要最低限の情報のみでジョブを作成可能である。図3にファイル配布ジョブのウィザード例を示す。

このため、自動化のためのスクリプトを作成する時間が短時間で済み、SREチームの作業を効率化することができる。



Googleが提唱するSERとは？

サイトリライアビリティエンジニアリング（以下SRE）とは、Googleが提唱しているシステム開発と運用の方法論であり、組織論です。
ITサービスの信頼性を高めるために「開発者と運用者の垣根を超えてより安定的な運用管理を行っていこう」「結果として信頼性向上につなげよう」というもので、従来の運用業務だけでなく、アプリケーション側のプログラム改善も含まれます。

新たなプログラムの導入やテスト、稼働状況の確認など、開発・運用における作業は多岐に亘りますが、その中には手作業や繰り返し行う必要のある作業、長期的に見て価値がないもの、戦術的ではないもの、サービスの成長に比例して増加するようなもの、といった作業が含まれます。これらの作業がトイル（労苦）と呼ばれるものになります。

参画時間が限られる開発者にとって、「トイルの軽減」、これがSREの成功に向けた課題となります。

トイルの軽減に自動化は必須

トイルの軽減に加え安定稼働を実現するには、できるだけ手作業は避け、ヒューマンエラーが生まれにくい環境にしなければなりません。そのためには自動化が必須になります。

自動化を実現するには、対象のシステムを構成するサーバーやネットワーク機器などのデバイスの構成情報の収集から設定変更、ファイルの配布などをすべてソフトウェアで行わなければなりません。

例えば、アプリケーションの実行環境を構築するためには、作業ひとつひとつに複雑な手順が必要ですが、インフラの構成手順をスクリプトにより自動化することで、ミスが撲滅でき、迅速な環境構築が可能になります。

自動化ジョブを作成するための最適なフレームワーク

運用自動化ツールのPOLESTAR Automationでは、自動化ジョブを作成するための最適なフレームワークを、ジョブ作成ウィザードという対話式の画面で実現しています。

ジョブ作成ウィザードはファイル配布や点検、差分チェックなどの業務を分析したうえで最適化した最小限の画面で表示します。ほとんどの設定はマウスによるクリックやドラッグ＆ドロップで実現でき、ファイル配布ジョブの作成には1分かかりません。図１にファイル配布ジョブ作成ウィザードによるジョブ作成手順を示します。

目的毎に、９種類のジョブ作成ウィザードが用意されています。図２にジョブ作成ウィザードの種類を示します。

サーバーの構築を例に取ると、一連の作業をスクリプトジョブとファイル配布ジョブ、バッチジョブを組み合わせて行い、テストサーバーと本番サーバーの環境の違いを監査ジョブで比較し、設定状況が正しいかどうか点検ジョブで確認する、といった自動化作業を、ジョブ作成ウィザードの利用により、短時間で行うことが可能になります。

また、監視ツールと連動しトリガーに引っかかったら、POLESTAR AutomationのRest-APIと連動して既存のジョブを実行させることもでき、SREでいうところのポストモーテム（検死)として、ログの収集、設定情報の確認などにもご利用いただけます。

図３に示すように、POLESTAR Automationをトイル軽減対策のプラットフォームとして利用していただくことで、SREの実現に向けた動きが加速できるのではないでしょうか。

まずは、評価版をご利用いただき、UIや機能をご確認ください。（評価版のダウンロードはこちら）
以上



今や日常語として世間に定着した感のある「コンプライアンス」。日本語では「法令遵守」と訳されるのが通例ですが、反社会的勢力との関係や脱税のような経済事犯といった、法令違反の根絶に加え、近年は環境保護や多様性への配慮といった社会的な規範まで、企業が守るべきものを指して、幅広い意味で用いられます。

近年はITの分野でも、コンプライアンスという用語が使われるようになりました。個人情報保護やサイバーセキュリティなどの文脈で出てくることが多いです。また、ITにおけるコンプライアンスの関連語彙として、「システム監査」という用語も時折目にします。

「システム監査」とは何か

「監査」という用語は、一般的には税務・会計や法務などの分野で使われます。
本来の意味は、法人やその他の組織、それに準ずる対象（個人事業主など）に対し、活動の正確性や妥当性、適切性などを、利害関係のない第三者が確認し、評価することです。
会社には法律（会社法）で「監査役」が定義されていたり、会計の世界には公認会計士による「監査法人」が存在したりと、制度としての（狭義の）監査は、社会に根付いているものです。

「ISMS（情報セキュリティマネジメントシステム）」や「プライバシーマーク（Pマーク）」などの第三者機関等によるコンプライアンス認証制度では、該当の認証機関による監査に加え、定期的な社内でのコンプライアンス調査実施が条件となっています。これらは、第三者ではなく当事者（社内組織など）による活動（内部監査）であり、広義の監査とでも呼ぶべきものでしょう。

「システム監査」は用途によって定義が異なる

「システム監査」という用語は、クライアント、サーバー、ストレージ、ネットワーク機器、クラウドサービスといった、企業やその他の事業主体が利用するITシステム全体において、構成や変更、その他利用状況全般を確認することを指す例が多いです。

システム監査は、先に述べたような、公的なコンプライアンス監査への対応を目的に実施されることもありますが、法的観点は含まれない場合もあります。法律等で規定されている用語ではないので、使う人によって、定義はさまざまです。
「ログ監査」「アクセス監査」「（設定）変更監査」のように、システム監査という括りの下で、さらに対象を限定して言及されることも少なくないです。

ITインフラにおいて「システム監査ツール」とか「システム監査機能」と呼ばれるものは、一般にサーバーやネットワーク機器の基本的な環境設定（configurationを略してコンフィグと呼ばれることが多い）、アカウントやパスワードを含むユーザー情報、アクセスログ、その他のログなどの変化を追跡できる、ツールや機能を指します。

OSやミドルウェア、アプリケーションを含むソフトウェアのインストールやアンインストール、ハードウェアの追加や取り外しなどの履歴管理や追跡は、構成管理に分類されるのが普通ですが、目的の観点からは、システム監査の枠内に含めても構わないでしょう。

システム監査はなぜ必要なのか

では、システム監査はどういったケースで利用されるのでしょうか？
管理者や持ち場ごとの実務者など、システムの規模が拡大すればするほど、1つのシステムに多くの関係者が携わることになります。

OSやアプリケーションにはたくさんのユーザーが作成され、1つのコンフィグが複数の実務担当者によって管理された結果、誰かが行った設定変更により、別の誰かが実施した変更との衝突が発生して想定外の挙動となり、システムトラブルなどの原因となることも少なくありません。

もちろん、コンフィグごとに特定の担当者にのみ変更権限を設定するなど、事前の対策方法もなくはないですが、実際の運用において、そうした細かい管理権限の適用は困難な場面があったり、逆に非常時の対応可能性を狭め、障害回復を遅らせる原因になったりするかもしれません。

本来の「監査」という用語が持つコンプライアンスの観点からも、システムの変更管理は大変重要です。
セキュリティ事案の原因は、ソフトウェア・ハードウェアそのものが持つ脆弱性によることも多いですが、権限やファイアウォールなど、人為的な設定ミスが招く場合も少なくありません。悪意を持った担当者がコンフィグやユーザー設定を勝手に変更し、意図的にセキュリティホールを開けてしまったり、マルウェアを内部から侵入させてしまうようなケースも、ひょっとしたらあるかもしれません。

セキュリティインシデント対応にシステム監査が必要

以上のようなシステム設定上のミスやセキュリティインシデントに対し、適確に、かつ素早く対処できるのが、システム監査機能です。クリティカルな設定項目を履歴追跡の対象にしておけば、いつ、誰がその変更を行ったのかを追跡できるとともに、復旧させるのも容易だからです。

システム監査機能を上手に活用し、安定したITインフラ運用を

コンプライアンス管理に限らず、日頃から定期的にシステム監査機能を用いて変更の追跡管理を行うことは、複数人が関与する運用上のトラブル防止を通じ、システム全体の安定した運用にも大いに役立つものです。

ITインフラ運用自動化ソリューション・POLESTAR Automationには、ここまで述べてきたようなシステム監査機能が搭載されており、あらかじめ対象として設定しておいたファイルやディレクトリ（フォルダー）などに対する、変更の追跡が可能です。
複数ユーザーが管理を共有するコンフィグファイル、ログなどを対象に、変更の追跡やキーワードの検出などを実行できるので、変更による不具合の原因特定、復旧に役立ちます。また、ディレクトリ監査により、意図しないファイルのダウンロードや、USBメモリーなどによる外部からの持ち込みも追跡できます。
効果的なシステム監査にも、POLESTAR Automationをお役立てください。



「ハイブリッドクラウド」の定義はさまざまです。AWS/Azure/Google Cloudのようなパブリッククラウド、自前でデータセンターなどに構築するプライベートクラウド、旧来の自社構内にあるオンプレミスシステムのうち、2つ以上の組み合わせと定義されることが多いようです。
本稿では、クラウド環境とオンプレミス環境を組み合わせたものをハイブリッドクラウドと定義します。

パブリッククラウドを利用する意義

やや自虐的なニュアンスも込めて、長らく「クラウド後進国」と呼ばれてきた日本ですが、パブリッククラウドの国内市場は最新の数字で少なくとも1兆円以上、調査内容の異なる別のデータでは1兆7265億円とされています。昨年はコロナ禍の初年度でもあり、オンサイト作業の不要なパブリッククラウドの導入や追加利用も増えたと思われ、前年比も概ね20%以上の伸長率となっています。

パブリッククラウドを利用するメリットについては、殊更に説明する必要もないかもしれませんが、サーバーやネットワーク機器、ストレージといったハードウェアの購入が必要なく、OS・ミドルウェアからアプリケーションまでがサービスとして提供されているため、調達・契約や導入作業の手間も省け、しかも使う分だけ支払う料金体系で、必要に応じてシステムの拡張や縮小が容易、というのが一般的な特徴です。
特に昨今、デジタル・トランスフォーメーション(DX)が叫ばれる中、短期間で業務のデジタルシフトを実施する手段として、導入作業が短期で済むパブリッククラウドの利用が増加する傾向にあります。

コロナで注目された新たな利点

これらに加えて、コロナ禍においては、先にも述べた「オンサイトでの構築作業が不要」という新たな利点がクローズアップされたように思います。従来は客先にサーバーやネットワーク機器を設置していたような案件が、リモートワークでの構築・保守が可能なパブリッククラウド上への構築にシフトして行った例も、少なくなかったようです。

一方で、日本が「クラウド後進国」とされてきた期間が長かった理由、今なおパブリッククラウドの導入を躊躇する企業が少なくない事情としては、セキュリティ全般に対する懸念があろうかと思います。中でも、データを自社の構内でない場所に配置することへの抵抗感は、多くの企業において根強いものがあります。さらに、各パブリッククラウドにおいて、大規模なシステム障害がここ数年繰り返し発生したことも、一定程度影響しているかもしれません。

パブリッククラウドの課題を解決する「ハイブリッドクラウド」

先進的なシステム管理者は、ここまでに挙げてきたようなパブリッククラウドの課題に早くから気づいていたようです。その解決策として提示されてきたのが「ハイブリッドクラウド」です。

ハイブリッドクラウドは、システム構成の一部をパブリック（公衆）の領域に置かず、自社の完全な責任範囲となるオンプレミスや、自社構築・自社専用のプライベートクラウドに置くものです。例えば、ユーザー登録や管理など、個人情報の取り扱いを伴うWebサービスをパブリッククラウド上に構築する場合、パブリック側にはユーザー向けの画面やサービスロジックだけを置き、個人情報はすべてオンプレミス、または自社専用のプライベートクラウドに配置・保存する、という構成があります。

ハイブリッドクラウドは、オンプレミスにあるシステムのクラウド以降の前段階、過渡期の消極的なシステムと理解されることもあるようですが、最近は最初からセキュリティの向上などを目的として、ハイブリッドクラウド構成を前提にシステム・サービスが設計される例も少なくないようです。

なお、ハイブリッドクラウドと類似の概念として「マルチクラウド」もあります。こちらは、複数のパブリッククラウドを組み合わせて使うことを指します。

パブリッククラウドといえば、AWSが半ば代名詞扱いを受けているような節があり、提供するサービスの量も質も圧倒的と言えますが、WindowsやActive DirectoryなどMicrosoft環境との親和性が高いのは、やはりAzureですし、Google CloudにはGoogleがパブリックなWebサービスを通じて磨き上げてきたAIなどの蓄積があったり、Kubernetesなど最新のコンテナ運用管理の発祥地であったりという、それぞれの特徴、得意分野があります。マルチクラウドの導入動機としては、現状はそうした適材適所での使い分けもありますが、大規模障害に備えたリスク分散という目的が多いようです。

ハイブリッドクラウドやマルチクラウドを上手に活用することで、セキュリティ上のリスクが低く、障害にも強いシステム構築が可能になるでしょう。

ハイブリッドクラウドの運用管理は、どうあるべきか

単一のパブリッククラウドを用いる場合、運用管理ツールもビルトインされたサービスとして提供されているのが一般的です。
AWSであれば「CloudWatch」というものがあります。オンプレミスの監視ツールと同等の監視ダッシュボードが構成でき、CPU・メモリ占有率、パブリッククラウド特有のクレジット（料金）などをモニターできるほか、アラート通知や障害復旧機能も搭載しています。

しかし、パブリッククラウドとオンプレミス/プライベートクラウドに跨るハイブリッドクラウドや、複数のパブリッククラウドを組み合わせるマルチクラウドにおいては、特定のパブリッククラウドに紐づくビルトインツールで、管理を賄うのは困難でしょう。ハイブリッドな環境では、やはり汎用の運用管理ツールが有用です。

POLESTAR Automationは、パブリッククラウドのインスタンスに対するクレデンシャル管理を搭載し、クラウドインスタンスもオンプレミスのサーバーと同様にエージェントやエージェントレスによる管理が可能で、ハイブリッドクラウド環境全体の一元管理に有用な運用自動化・構成管理ツールです。
ハイブリッドクラウドでも、ぜひともPOLESTAR Automationをお役立てください。

＜おすすめコンテンツ＞
・導入事例：大手通信キャリア様構成管理自動化事例



情報流出・漏洩やランサムウェア（データへの身代金要求）被害などのサイバー犯罪、セキュリティ事案が絶えません。
インターネット上のニュースサイトには、毎日のように国内外のサイバー犯罪に関する記事が掲載されますが、特に近年は名だたる有名企業が、取り返しの付かなさそうな深刻な被害に遭う事例も増加しています。
企業を対象とした調査ではありませんが、ノートンライフロック社（旧シマンテック社）が2021年2月に消費者を対象に調査し、5月に公表したデータによれば、調査時点から過去12か月間に、日本では約1,800万人以上がサイバー犯罪の被害に遭い、被害額は日本だけで推定220億円に上るといわれています。
企業では、これをはるかに上回るサイバー犯罪の被害が発生しているものと思われます。被害額は直接的なものだけでなく、間接的かつ算出しにくい企業の信用にも及ぶでしょう。顧客情報などの流出事案はもちろんですが、エンドユーザーには直接影響のないランサムウェア被害も、遭ってしまうと脇の甘い企業という印象を与え、企業イメージ上よくないものです。

■企業はどんなサイバー犯罪に遭っているのか

企業におけるセキュリティ事案の類型には、次のようなものがあります。

1. システムの脆弱性（主にソフトウェアの不具合が原因ですが、ハードウェアの仕様に起因することも）に対する攻撃
2. マルウェアによる不正アクセス（フィッシング詐欺や添付ファイルへの混入など）を通じた情報漏洩・システム破壊
3. 内部犯行（現職従業員や退職者等によるデータ持ち出しや意図的なマルウェア混入）

1.～3.のいずれかの手段で、特定の組織（企業や官公庁など）を対象に、何らかの意図を持った攻撃者が行うものを「標的型攻撃」と呼びます。セキュリティホールを突いて侵入することもありますが、メールを用いてマルウェアを侵入させ、社外秘を含むデータを流出させるケースが多いようです。
ここ数年はデータを暗号化させて閲覧不能にし、暗号化を解除する条件として身代金を要求する「ランサムウェア」の被害も増加しています。

従来、セキュリティツールといえば「アンチウイルス（ウイルス対策ソフトウェア）」が代名詞的存在でした。セキュリティホール（脆弱性）の検出機能などを持つものもありますが、基本はマルウェアの発見と削除/隔離が目的です。
アンチウイルスは「パターン」と呼ばれる個別のマルウェアの情報をデータベース化したものを、ローカルのPC上またはクラウドに配置し、その内容に基づいてマルウェアファイルの存在やシステムプログラム・データファイルの改変などをチェックする仕組みです。

■「ゼロデイ攻撃」は防げるか？

今も多くの企業では、何らかのアンチウイルスを導入していることでしょう。
しかし、マルウェアは世界中の攻撃者によって日夜新たなものが生み出されていますし、著名なソフトウェアの脆弱性も、次々と明らかになっています。新しいマルウェアをアンチウイルスのベンダーが発見・分析し、パターンとして配布・利用可能にしたり、ソフトウェアのベンダーが対策パッチを提供したりするまでには、時間を要します。
この対策前のタイミングで行われるサイバー攻撃を「ゼロデイ攻撃」と呼びます。

ゼロデイ攻撃そのものは、直接の対応策がない状態で行われるものであり、完全に防ぐ手段は原理的にありません。
「ゼロデイ攻撃対策」を謳うさまざまなセキュリティ製品が出回っていますが、導入しただけで、ゼロデイ攻撃に対する完全な防御が実現できるようなものは存在しません。
ゼロデイ攻撃に対しても最も有効なのは、パスワードの複雑化やログインの多重化、重要データやその配置先であるストレージへのアクセス権の厳重かつ徹底した管理、ネットワークへのファイアウォールやホワイトリストの導入など、一般的かつ基本的なセキュリティ対策でしょう。
近年「ゼロトラスト」というキーワードもよく耳にします。「誰も信頼しない」セキュリティ、という考え方で、やはり「ゼロトラストセキュリティの実現」を掲げる製品が数多くリリースされていますが、セキュリティ対策の基本を怠らず、セキュリティ製品に過剰に頼りすぎない姿勢こそが、真のゼロトラストであると言えます。

■適切なポリシーの確立と運用こそが、最善のセキュリティ対策

上で述べた「一般的かつ基本的な対策」には、社内で定めたセキュリティに対するポリシーが、きちんと適用されているかを定期的に確認することも含まれ、かつ、非常に重要といえます。
ITインフラ運用自動化ソリューション「POLESTAR Automation」を用いると、パスワードの複雑性や、サーバーやその上にあるプログラム・データに対するアクセス権限の確認、アクセスログの取得、セキュリティホールに対するパッチ適用とその結果確認など、セキュリティポリシー適用の状況把握に必要な情報の収集と対策の実行が、手軽に行えるようになります。
日常の運用自動化・省力化はもちろん、セキュリティ管理の充実にも、POLESTAR Automationをぜひともお役立てください。

＜おすすめコンテンツ＞
・活用事例：CISCOスイッチ/ルータ　パスワード変更の自動化



世は「クラウド万能時代」といわれます。
従来、何かのシステムを立ち上げるには、サーバーやネットワーク機器をはじめとするハードウェア、OSやデータベースのようなソフトウェア一式を揃えなければならなかったのが、クラウドサービスの出現により、そのような初期投資に費用を掛けることなく、利用料金を払うことで構築可能となりました。

■クラウドが新しいクラウドを産む。クラウドのエコシステム

クラウドのメリットといえば、機器購入や開発のための初期投資が最小限で抑えられ、ランニングコストだけで運用できることが挙げられるでしょう。
最近では、自社で新しい技術を開発する代わりに、クラウドでサービスとして提供されているサービスを利用することも拡がっています。
クラウドが活用されている代表的な例に、AI（人工知能）があります。AIのエンジン部分、つまり、機械学習や深層学習（ディープラーニング）のロジック開発に新規参入しようとしても、既にAI開発で長い歴史と実績を誇る米IBMの「Watson」をはじめ、GAFAに代表される巨大IT企業が、日本円換算で何千億円とか何兆円といった莫大なコストを投じて行ってきた既存のAIエンジンに勝つのは難しいです。
エンジン開発以上に、AIが目論見通りに機能する上で重要なのは「学習」です。「ビッグデータ」という呼び名の通り、精度の高いAIを実現するには、AIに学習させるデータは多ければ多いほどよいです。
しかし、AIを用いたクラウドサービス、例えばチャットボットや音声認識のサービスは、数多くのベンチャーやスタートアップ企業からもリリースされています。中にはスクラッチ（無の状態）から自社開発されたものもありますが、多くはAIエンジンから開発したのではなく、先行企業がクラウドで提供しているエンジンやビッグデータを利用し、フロントエンドだけをオリジナルで開発して提供されているものが少なくないです。
そうしたサービスが提供される基盤となるサーバーやデータベースの構築にも、AWSやMicrosoft Azure、Google Cloudといった、いわゆるパブリッククラウドのITインフラが主に用いられます。
毎日のように、新しいものがリリースされているクラウドサービス。その多くは、こうして既存の別のクラウドサービスを組み合わせて提供されているのです。クラウド上でクラウドどうしが結合し、新たなクラウドを産み出す、クラウドネイティブのエコシステム（生態系）が構築されたといえるでしょう。

■世界に比べてまだまだ低い、日本のクラウド利用率

総務省の令和2年（2020年）版「情報通信白書」によれば、企業においてクラウドサービスを一部でも利用している企業の比率は64.7％となっており、前年の58.7％から6.0ポイント上昇しています。
この統計は、ITインフラを主体とするいわゆるパブリッククラウド(Iaas=Infrastructure as a Service)だけでなく、クラウドストレージサービスのようなファイル保管・共有系、電子メール、ビジネスチャット/コラボレーションツール、最近ではビデオ会議やデスクトップ仮想化(VDI)といった、あらゆるジャンルのクラウドサービスを合計した数字です。
新規で構築したシステムもあれば、かつて自前で構築する形（オンプレミス）で運用されていたものを、クラウドとして外部に出したものも含まれるでしょう。
こうした広義のクラウドサービスの利用率は、新しいBtoBサービスや古い既存サービスの置き換えの多くが、パッケージではなくクラウドで提供されていることもあって、伸び続けていくものと思われます。
しかし、サーバーやデータベース等のITインフラをクラウドに配置するIaaS(Infrastructure as a Service)だけで見ると、米国の大手市場調査会社であるガートナー社日本法人による最新の調査では、日本企業における利用率は、22%にとどまります。ガートナー社の別のデータでは、日本はクラウドへの支出額の伸長率からみて、クラウド普及が最低レベルの「抵抗国」であるとされてもいます。
世界的に見て高くないといわれる日本のクラウド利用率ですが、それでも社外向けのWebサイトや対外提供用のWebサービスなどは、ほとんどクラウドに置いて行く流れになっているようです。
クラウドに置かれないのは社内システムで、日本での利用が進まない理由として挙げられるのは、主にセキュリティ面での理由、つまり個人情報のようなセンシティブなデータはできるだけ社内に置いておきたい、というものですが、その結果、必ずしもオンプレミスに置いておく必要のないものまでオンプレミスに残り続けている、ということになっているように思います。

■クラウド時代のITインフラ運用は？

それでも、サーバーのハードウェアやOS、ミドルウェアなどが数年で陳腐化するリスク、人件費を含む保守の負担、災害対策などのBCP（事業継続計画）を理由に、ITインフラの大きな流れとしては、日本でもクラウド化に向かっているのは確実と思われます。
ITインフラをクラウドに置く、というのは、自社内や自社で借りているデータセンターのオンプレミス環境にあった既存システムを、クラウド環境に移行したり、クラウド上に新規に構築することです。
しかし、システムの動作する環境、つまりハードウェア、OS、ミドルウェアは、実はオンプレミスもクラウドも大差ありません。
オンプレミスのサーバーと同様、クラウドにもIntel系プロセッサで動作するサーバーインスタンス（最近はArmプロセッサのインスタンスも出てきているようですが）が構築でき、適切なスペックのプロセッサやメモリ、ストレージを選択・確保してインスタンスを作成し、オンプレミスと同じOSとミドルウェア、アプリケーションをインストールします。
それぞれのインスタンスは「VPC」などの名称で呼ばれる仮想LAN上に置かれ、同一の仮想LAN上にあるインスタンスどうしはプライベートIPで接続させることも可能です。
つまり、死活・性能監視や構成管理、OS・ミドルウェア・アプリケーション等のアップデート、監査、レポーティングなど、ITインフラ運用で行うべきタスクは、オンプレミスでもクラウドでも大差ないのです。

■オンプレミスの運用自動化資産を、クラウドにも活かす

オンプレミスからパブリッククラウドへの移行で何か変わるとすれば、インスタンスの利用時間やトラフィックで課金されるというクラウドのビジネスモデルに加え、ハードウェアをクラウドベンダーが提供・保守してくれるので、いわゆる「ハード的故障」から、実質的に解放されることでしょうか。
しかし、ハードウェア以外のリスクは、オンプレミス同様にユーザー自らが管理して行かなければなりません。ITインフラの運用管理には、オンプレミスで実績のあるツールが、クラウドでも役立つといえるでしょう。

ITインフラ運用自動化ソリューション「POLESTAR Automation」は、オンプレミスはもちろん、クラウドでも威力を発揮する、構成管理と点検・監査のためのGUI型ツールです。
「ジョブ」という概念で提供される運用管理タスクは、クラウド環境でもそのまま実行でき、役立つものばかりです。
オンプレミスのサーバーと同様、エージェント方式でインスタンスを運用管理できるほか、公開鍵の集中管理機能も搭載し、鍵認証が一般的なクラウドでも、エージェントレス方式による運用自動化を安全に実現します。
オンプレミスでも、クラウドでも。ITインフラ運用にはPOLESTAR Automationをお役立てください。



ITインフラの構築や運用・維持管理に携わる、管理者や最前線に立つ担当者の皆様の間で、近年「構成管理ツール」という用語を目や耳にする機会が増えてきたと思います。

ITインフラ運用管理における「構成管理」とは、ITインフラを構成するサーバーやネットワークなどのハードウェア、オペレーティングシステム(OS)、ミドルウェア、アプリケーションといったソフトウェアの稼働状態を把握し、期待された状態を維持するための、運用管理上のプロセスを指します。

そうしたプロセスを手作業によらず、自動的に行うのが「構成管理ツール」というわけですが、ここではもう少し詳しく、構成管理の具体的な中身と、なぜ構成管理ツールが必要なのかについて、解説します。

■そもそも「構成管理」とは何か

例えばサーバーにおいて、メモリやストレージの容量、OSやミドルウェアの種類とバージョン、パッチの適用状態、設定変更などに影響され、新たに構築・導入したITサービスが正常に稼働しなかったり、稼働していたものが稼働しなくなったり、といったことが往々にしてあります。

そのようなケースでは、サーバーの仕様を適切に把握していれば、例えばパッチをロールバックしたり、変更した設定ファイルの内容を元に戻すなどの対応で、問題の解決が可能です。これが最も基本的な構成管理といえます。

管理するサーバー台数の少ない運用現場では、サーバーの基本的なハードウェア・ソフトウェア構成を、Windowsではsysteminfoやmsinfo32、Linuxなどではcpuinfoやdf、uname、lsmodといったコマンドを実行して確認し、紙やExcelファイルなどに書き出して文書化するという一連の構成確認業務が、手作業で行われているようです。

OSパッチの適用や周辺ハードウェアの増設といった変更があれば、作成した文書を随時更新して行く、という具合です。

しかし、管理台数が増加してくるにつれ、このような手作業による構成管理は煩雑になる一方でしょう。徐々に疎かになり、結果の更新を忘れてしまった結果、いざという時の復旧対応に、不必要な時間と手間を掛けてしまうことにもなりかねません。 また、対象がルーター・スイッチのようなネットワーク機器の、コンフィグ管理や変更作業となると、対象台数がサーバーの数倍になることも多く、作業に長い時間と人員が投入されることになります。

■自動化、省力化と作業フローの標準化

こうしたITインフラ環境の構成管理における構成情報の取得や更新・変更を、手作業によらず自動的に実施できるのが、構成管理ツールです。

「運用自動化ツール」と呼ばれることもあります。ITインフラでいう「運用自動化」の本質は構成管理にあることから、構成管理ツールという呼称の使用が増えている傾向にあるようですが、本質的な違いはありません。 構成管理ツール、ないしは運用自動化ツールを導入する直接の目的は、まずは多数の管理対象機器を相手に手作業で実施していた煩雑な構成管理業務を、自動化・省力化することにありますが、構成管理の徹底によって得られるもっとも意義ある収穫物といえば、構成管理業務や構成そのものの「標準化」でしょう。

構成管理ツールを適切に使用することで、まず、構成管理業務の作業手順が標準化されます。もちろん、導入してただちに使えるというものではなく、最初に従来の手作業を構成管理ツールのワークフローに移し替えるステップを踏むことになりますが、そこをクリアすれば、あとは構成の把握や維持、変更などが標準的な手順で行えるようになります。

ヒューマンエラーの低減も、大きなメリットです。コマンドの打ち間違いのような些細なミスから、誤った作業手順の実行による大きなトラブルまで、手作業で発生しがちな作業エラーの発生を、未然に防止できる効果があります。

■属人化の排除、熟練エンジニアのノウハウ継承

構成管理ツールの異称のひとつに「ランブックオートメーション(RunBook Automation=RBA)」というものがあります。ランブックとは「手順書」のことで、「手順書に基づく自動化」と訳されます。

構成管理ツールが登場する前、大規模なITインフラ運用の現場では、構成管理業務をテキストエディタやWord、Excelなどで作業手順書を作成し、記述するということがよく行われていました。多くは、熟練した運用エンジニアによって作成され、作業実行のためのシェルスクリプトやバッチファイルなども、セットになっていたものです。

しかし、他人、特に熟練エンジニアが作成した手順書やスクリプトは、その人がその時点の構成を反映して書いたものです。ハードウェアやOSなどの変更内容を、常に反映し、更新し続けて行かなければなりません。

また、作業内容が複雑であればあるほど内容も高度になり、新人や経験の浅いエンジニアが読みこなし、活用するには、高いハードルがあることも少なくありません。

特定の作業が、特定の人に結び付いてしまうことを「属人化」といいます。手作業の多い運用現場では、属人化が当然のように起きています。熟練エンジニアの突然の退職や、病気等による長期の離脱は、手順書をもってしても解決し難いものがあります。

構成管理ツールにサーバーやネットワーク運用の作業手順を組み込むことは、手順書を残すのと同じです。しかし、手順書を解釈するのは人ではなく、構成管理ツールというコンピュータープログラムであり、解釈のズレによるミスは原理的に起こりえません。

同じ操作を何度繰り返しても、同じ結果が得られることを「冪等性(べきとうせい、idempotence)」と呼びます。本来は数学用語ですが、IT、特に構成管理の分野でも同様な意味で用いられています。

構成管理ツールによる自動化された運用では、誰がいつ実行しても結果は同一です。構成管理ツールの導入は、運用業務に冪等性をもたらし、属人化問題の解決に役立ちます。

■GUIベースの構成管理ツールで、運用にまつわる積年の問題を一気に解決！

では、構成管理ツールにはどんなものがあり、何を選べばよいのでしょうか？

基本的なライセンス形態としては商用とOSS（オープンソース・ソフトウェア）があり、商用製品には買い取り+保守とサブスクリプション型があります。

ユーザーインターフェースはCLI（コマンドライン）とGUI主体のものに分かれますが、GUIベースを謳っていても、CLIベースの構成管理ツールにGUIからのコマンド実行機能を追加した程度のものから、最初からGUIを前提に設計され、あらゆる操作と結果の収集・管理がGUIで可能なものまで、幅広いです。

とりあえず無料でスタートできるということで、OSSの構成管理ツールが利用されることも多いのですが、大半はCLIベースで、しかも手順書にあたるファイルの記法や関数などは、そのツールに固有なものです。つまり、手順書記述を学習する必要があり、習熟の度合いによって実現可能な構成管理作業の水準に差が出やすくなります。結局は学習した人にしか使えないツールであり、新たな「属人化」を生んでしまいかねないというジレンマを抱えてもいます。

標準化、冪等性、属人化の排除といった構成管理ツール導入の本来の目的を達成するには、GUIベースで設計されたものの方が適しているといえるでしょう。

ITインフラ運用管理ソリューション「POLESTAR Automation」は、ここまで説明してきた構成管理ツールとしての機能を一通り備えながら、他のツールにはない特徴も備えています。 特に、構成情報を自動的・定期的に取得し、SOE（Standard Operating Environment=標準運用環境）の考え方に基づいて達成率（充足率）を表示する「点検」機能、構成情報の変更を追跡して変更点を容易に把握可能な「監査」機能、構成情報の共有に欠かせない「報告書（構成を記述・整理した報告書の作成）」の出力を自動化できるレポーティング機能は、POLESTAR Automationならではの機能といえます。

完全にGUIベースで設計された商用ツールながら、OSSを保守サービス付きで導入するのに匹敵する低価格で導入でき、しかも予算や管理対象機器の台数に応じて、ライセンス買い取りとサブスクリプションの2種類の導入体系が選べます。

＜おすすめコンテンツ＞
・CISCOスイッチ/ルータ　パスワード変更の自動化



4月25日、東京都と関西3府県を対象に、新型コロナウイルス感染拡大に伴う3回目の緊急事態宣言が発動されました。出口の見えないコロナ禍の、さらなる長期化が懸念されるところです。
昨年来のコロナ禍は、経済活動のあらゆる分野に影響を及ぼし、特に雇用については深刻な事態となっています。
1月29日の厚生労働省発表によれば、2020年の平均有効求人倍率は1.18倍と、前年比0.42ポイントの減少。有効求人件数は前年比21%減なのに対し、有効求職者は6.9%増となり、求職者の増加に対して求人が減ったといえます。
4月8日には、同じく厚労省から、コロナ禍による解雇・雇い止めが10万人を超えたとの発表もありました。
しかし、IT業界、特にエンジニアの求人については例外で、人材関連サービス各社のデータを見る限り、最初の緊急事態宣言が出された2020年4月から6月頃まで一時的に低調であったものの、7月以降は回復に転じ、コロナ禍前と変わらないか、上回る水準にまで戻っているようです。

■先進企業は自社でITエンジニアを雇い、育て、囲い込む

4月6日付日本経済新聞の記事「金融、IT競争力が左右」によれば、米国の大手銀行では全従業員に占めるITエンジニアの割合が30%なのに対し、日本は4%に留まるという、非常に衝撃的な数字（金融庁調べ）が紹介されています。
国内の大手銀行で発生したシステム障害を受けての記事ですが、基幹システム運用を担う専門人材を減らしてきたことが、原因のひとつとしています。

一方、合併によって誕生した、このメガバンクでは、合併前の各銀行からシステムの外注を請け負ってきた既存のITベンダーが、合併後も引き続き担当し続けているだけでなく、新規に参加したベンダーも加わってなおさら混沌とした状況となったまま、20年近くかけてシステム統合を実施してきたことが知られています。
多くの欧米の金融機関では「金融=テクノロジー」と捉え、技術革新をリードできる優秀な自社ITエンジニアの確保と、囲い込みのための投資を続けています。
対して日本では、システム開発から運用までを外部に丸投げするのが一般的で、しかも融資系列や合併など各種のしがらみから、複数のITベンダーに委託するケースが少なくないようです。
金融に限らず、日本の多くの産業分野に根深く存在する複雑な外注システムについては、日本独自の構造的な問題点、国際競争力を削ぐ要因として、海外事情に精通するITコンサルタントやアナリストにより早くから指摘されてきました。
しかし、一朝一夕にグローバルスタンダードをキャッチアップするのは、簡単なことではありません。

■コロナ禍にあっても「DX」で激化するIT人材争奪戦

そんな課題を抱える日本の産業界ですが、前述の通り、ITエンジニアの求人は堅調です。
理由としては、コロナ禍のもとテレワークなどの特需で伸びた通信関連業種のような、いわゆるニューノーマル需要への対応もあるでしょうが、やはりここ数年、ITに限らず全産業分野において最重要課題となっている「デジタル・トランスフォーメーション(DX)」への投資が背景にあると考えられます。
「脱はんこ」のような職場の日常から、社会インフラの根本に至るまで、ありとあらゆる分野をデジタル化、IT化して行こうという「DX」の推進が叫ばれて久しいです。
DXは産業構造の変革という側面も持っており、人材を含む投資対象やプライオリティにも変化をもたらしています。変革の前段階、ないしは変革中にある現時点で求められるのは、デジタル化を担うIT人材です。

「働き方改革」もDXを構成する主要なテーマのひとつであり、昨今のコロナ禍で爆発的な需要を呼んだ高速ネットワークやVPN、リモートアクセスへの投資も、DXの一環であると捉えることができます。
DX以前から、余力のある企業が先行したIT投資ですが、DXの進んだ世の中では、末端の取引先にまでDXへの対応が求められることになり、否が応でもDXを受け入れるための投資を迫られることになります。
その結果、限られたITエンジニアのパイが争奪戦状態となります。終身雇用制が実質的に崩壊してしまったといえる現状では、人材の流動性も高まり、より条件のよいところに優秀な人材が流れて行くことになるでしょう。
結局、DXの時代になっても、十分な投資ができ、必要な人材を目論見通りに集められるのは、やはり業績がよく、中長期的な将来性も期待できる企業、業種ということになってしまうわけです。

■大変革と人材不足の時代に、生存を図るための投資 – 運用自動化

さて、DXに適応し、遅れを取らないためのITエンジニアの争奪戦が発生し、人材確保に苦労する時代を、限られたリソースのもとで生き抜く方法はないのでしょうか？
それは、導入しやすく、少ない人数でも運用・維持しやすいITインフラの環境構築に投資することです。
優秀なIT人材の確保が困難となる中、限られた人数でもITインフラ運用の品質を維持し、向上できる手段として注目を集めるのが「運用自動化ツール」です。
従来、人手に頼ってきたサーバーやネットワーク機器の日常点検、設定変更・アップデートなどの構成管理、障害対応などを自動化できるだけでなく、作業手順の標準化により、誰が作業しても同じ結果が得られる「冪等（べきとう）性」の獲得と、作業が特定の人物に紐付く「属人化」の排除にも役立ちます。
中でも、ワイドテックの「POLESTAR Automation」は、コマンドラインが主流の競合製品と比べ、日常の運用業務の大半をGUIベースのマウス操作でこなせる、扱いやすい運用自動化製品です。
しかも、競合製品と同等かそれ以下の費用で利用可能な価格体系で提供するとともに、無償提供の自動化ジョブライブラリも充実しています。
DXで迎える大変革の時代で生き残るために。そして、いつか迎えたい逆転攻勢の日に備えて。POLESTAR Automationが、きっと貴社のお役に立てると確信しています。



先日、米国のコンピュータ緊急事態対策チーム（US-CERT）が、オープンソースのSSL/TSLライブラリ「OpenSSL」に新たな脆弱性を発見したことを報告した。共通脆弱性評価システムCVSSにおける深刻度は「重大」で、この脆弱性を突かれると、サービス妨害攻撃（DoS）につながる可能性がある。
影響するバージョンは、OpenSSL 1.1.1から1.1.1hまでと、1.0.2から1.0.2wまでの全てである。
脆弱性に対処したバージョンであるOpenSSL 1.1.1iと1.0.2xは既に公開されているが、現在サポートされているバージョンはOpenSSL 1.1.1系のため、OpenSSL 1.1.1hまではもちろん、1.0.2系のユーザーにもOpenSSL 1.1.1iへのアップグレードが推奨されている。

運用自動化ツールPOLESTAR Automationには点検ジョブ機能があり、あらかじめ設定された点検ポリシーに基づいてチェックを実施し、結果を「遵守」か「違反」でGUIのダッシュボードや報告書に出力できる。
この機能により、運用中のサーバに点検を掛けることで、脆弱性のあるOpenSSLを利用しているサーバを簡単かつ瞬時に識別・特定できる。

図１～3に、OpenSSLバージョン確認点検ジョブの結果を示す。

図１　OpenSSLバージョン確認ジョブ実行結果

図２　OpenSSLバージョン確認ジョブ詳細表示 (OpenSSLバージョンが1.1.1iの場合に遵守)

図3　OpenSSLバージョン確認ジョブ詳細表示 (OpenSSLバージョンが1.1.1i以外の場合に違反)

POLESTAR Automationでは、オプションとしてレディメイドの点検ポリシーを全部で200種類以上作成しており、OSや対象機器に応じて利用可能である。
OSはWindows、Linux、SunOS、HP-UX、AIX用の５種類、対象はOS、ハードウェア、脆弱性点検用となっている。
レディメイドの点検テンプレートを利用すれば、導入した当日から点検が可能になる。

今回ご紹介したOpenSSLバージョン確認のための点検ポリシーは、お客様の検証用に作成したもので、現在は無償で提供している。

POLESTAR Automationならではのユニークな点検ジョブは、最も優れた点検の手順・内容（ベストプラクティス）を点検ポリシーとして登録し、実行できる機能である。
POLESTAR Automationを運用自動化のプロセスに組み込むことで、属人性を排除しながら、業務の標準化も実現可能となる。
POLESTAR Automationの年間利用料金は、サーバ10ノードで12万円（税別）からで、小さく始めて大きく育てることが可能である。