世の中には多くのITシステム、サービスが存在しますが、それらを稼働させるためには「ITインフラ」が欠かせません。さまざまな場面でITが活用される今、どのような企業でもITインフラの構築・運用が必要になってきています。
しかし、ITインフラという言葉は知っていても、その中身についてはあまり詳しくないという方も多いのではないでしょうか。
この記事では、ITインフラの概要から構築の注意点、見直し方法までを整理して解説します。
一般的に「インフラ(インフラストラクチャー)」といえば、電気・ガス・水道、道路や公共施設など、生活を送る上で欠かせない「基盤」のことを指します。
同じようにITインフラは、IT分野における基盤となるものです。コンピューターやサーバーといったハードウェアのみを指すこともあれば、より広く、OSやミドルウェア、ネットワーク回線、運用監視なども含めたものを指す場合もあります。本記事では後者の、広い意味でのITインフラについて取り上げます。
ITインフラは、単一の機器ではなく、複数の要素が組み合わさって成り立ちます。代表例は次のとおりです。
例えば企業においてITインフラを構築するといえば、自社専用のサーバー環境を用意し、ネットワークや認証、監視・バックアップの仕組みまで含めて「継続的に使える基盤」を整えることを意味します。
企業や組織でITインフラを用意するにあたっては、堅牢でありながら利便性の高いものを構築する必要があります。脆弱なITインフラを構築してしまうと、サイバー攻撃の被害に遭いやすくなり、環境の変化にも柔軟に対応しにくくなります。かといって堅牢さのみを追求して利便性を軽視すると、生産性の低下を招きかねません。
昨今はテレワークの普及もあり、ITシステムへのアクセスは社内ネットワークからだけとは限らなくなりました。クラウドサービスの業務利用も増えているため、社外からのアクセスも前提に、アクセス経路とセキュリティ対策をセットで設計することが重要です。
特に、IDとパスワードだけに依存した認証や、過度に広い権限付与は、侵害時の影響を大きくします。多要素認証(MFA)や最小権限、端末の健全性確認、ログ取得などを組み合わせ、「侵入されない」だけでなく「侵入されても拡大しにくい」設計が求められます。
ITインフラは、常時利用できる状態をできるだけ維持し続けなければなりません。そのためには、サーバーやネットワーク経路の冗長化が欠かせず、仮に一部で障害・不具合が発生しても、基盤としての機能を維持できる構成が理想です。
ただし、高い可用性を求めるほど、コストや運用の複雑性も増える傾向があります。業務影響(止まった場合の損失)を踏まえ、目標とする可用性や復旧時間(RTO)・復旧時点(RPO)を現実的に設定しましょう。
ITインフラは構築後の運用が品質を左右します。監視、脆弱性対応(パッチ適用)、構成変更管理、バックアップ検証、棚卸しなどを継続的に回せる体制まで含めて設計することが重要です。
ITインフラは、自社にインフラエンジニアなどの専門人材がいれば独力で構築することもできます。この場合、ITインフラを構成する要素は多岐にわたるため、担当部署が複数に分かれることもあります。
専門人材がいなかったり、検討や維持に十分な時間を割くことが難しかったりする場合は、ITインフラの構築から運用までを外部に委託することも可能です。インフラ構築のためのパッケージやソリューションを用意している業者も多く、また、セキュリティの部分だけ専門企業に依頼するといった進め方もあります。
ITインフラを見直して更改する場合も流れは同様です。何を目的として、どのような機能が必要なのかを要件定義として最初に固め、設計・構築・テストへとつなげます。はじめに目的や機能を明確にすることが、手戻りを減らすうえで特に重要です。
また、構築後も常時監視するような運用が必要です。障害や性能劣化、セキュリティ上の異常は「早く気づく」ほど影響を小さくできるためです。
新規にITインフラを構築するだけでなく、既存インフラの老朽化や事業環境の変化により、見直しが必要になることもあります。最近ではオンプレミスからクラウドへ移行するケース、あるいはオンプレミスとクラウドを併用するハイブリッド構成を採用するケースも増えています。
見直しの第一歩は、現状把握と課題の洗い出しです。次の観点で棚卸しすると整理しやすくなります。
クラウドは便利ですが、「勝手に安全」「勝手に止まらない」わけではありません。責任分界(どこまでが利用者側の責任か)を理解し、認証・権限、ネットワーク、ログ、バックアップ、復旧の設計を再確認しましょう。
また、ITインフラが変わると、その上で稼働しているITシステムにも大きな影響を及ぼします。ひとつの基盤上に複数システムが稼働していることも珍しくないため、各システムへの影響(通信要件、IP設計、認証連携、バッチ処理、保守時間など)を事前に確認することが重要です。
利便性の観点では、普段から利用者・管理者の意見を集めて記録しておくと、見直し時の判断材料になります。
ITインフラの構築・見直しは計画的に進めましょう。
ITインフラはすべてのシステムの基盤であるため、構築や更改の際にはセキュリティ、利便性、障害対策(可用性)の3点には特に注意が必要です。
オンプレミス、クラウド、ハイブリッドなど方式の選択肢は広がっていますが、どの方式であっても「目的の明確化」「要件定義」「運用まで含めた設計」が欠かせません。新規構築でも更改でも、手戻りを減らすために計画的に進めましょう。
A. ITシステムやサービスを稼働させるための基盤全体を指します。サーバーやネットワークなどのハードウェアだけでなく、OS、ミドルウェア、認証、監視、バックアップなど運用要素まで含めることが一般的です。
A. ITインフラは「土台(基盤)」、ITシステムはその上で動く「業務アプリケーションやサービス」です。インフラが止まると、その上の複数システムが同時に影響を受けることがあります。
A. 代表的にはサーバー/仮想化、OS/ミドルウェア、ネットワーク、ストレージ/バックアップ、認証・ID管理、監視・ログ、障害対策(冗長化・DR)などがあります。
A. 目的の明確化と要件定義です。対象業務、利用者、必要な性能、可用性、セキュリティ、運用体制、予算などを整理し、方式選定(オンプレ/クラウド/ハイブリッド)につなげます。
A. 社外アクセスを前提に、認証強化(多要素認証など)、最小権限、端末管理、ログ取得と監視を組み合わせることが重要です。「侵入を防ぐ」だけでなく「侵入後に拡大しにくい」設計も意識します。
A. 重要度によります。止まった場合の業務影響を踏まえ、目標とする可用性や復旧時間(RTO)・復旧時点(RPO)を設定し、必要な範囲で冗長化やバックアップ、DRを設計します。
A. 不要にはなりません。クラウドでも利用者側の責任(認証・権限、設定、ログ、バックアップ、監視など)が残ります。責任分界を理解し、運用設計を見直すことが重要です。
A. 機器の老朽化、性能不足、障害の増加、運用の属人化、セキュリティ要求の変化、クラウド利用拡大、コスト増などが代表的です。現状把握と課題整理から始めると進めやすくなります。
A. そのインフラ上で稼働するシステム一覧と依存関係(通信、認証連携、バッチ処理、保守時間、外部接続)を棚卸しし、移行・切り替え時の影響と手順を計画に落とし込みます。
A. 要件定義の粒度を上げ、運用(監視、障害対応、変更管理、SLA)まで含めた責任範囲を明確にすることが重要です。構築後に「誰が何をするか」が曖昧だと、品質が落ちやすくなります。