セキュリティって何？？
インフラエンジニアが知っておくべきセキュリティ知識は？
インフラエンジニアだが、セキュリティ設計を担当することになった。基礎知識をざっくりと把握したい

上記のような方の悩みに答えます。

本記事を読むことで、インフラエンジニアとして知っておくべきセキュリティ知識が理解できるようになっています。
具体的には以下の７つです。

アクセス管理、権限管理（内部犯対策）
暗号化
ウイルス対策
サイバー攻撃手法
不正通信対策（WAF、IDS、IPS）
ネットワーク分割
脆弱性対策

実際に筆者が「理解しにくいと感じた」且つ「理解しておくことで業務効率が上がる」セキュリティ基礎知識をまとめました。
インフラエンジニアに求められるセキュリティ知識はセキュリティエンジニアに比べて多くはありません。
多くは用語を聞いたことがあるレベルでも大丈夫だと考えています。

筆者はインフラエンジニア歴10年です。
大規模ECサイトのAWS運用やAWSの技術コンサル的な立場で仕事をさせてもらっています。
AWS資格は7冠（SAA、DVA、SOA、SAP、DOP、MLS、DAS）取得しました。
筆者のスキルセットはこちら

※本記事は他サイトの画像引用していますが、引用元のリンクは最後に記載しています

インフラエンジニアのセキュリティ知識７選

セキュリティとは

セキュリティとは具体的には「ISO/IEC 27002」、「JISQ27000」で定義されており、「機密性(Confidentiality)」「完全性(Integrity)」「可用性(Availability)」の3要素を維持する意味の「CIA」が示されています。

機密性（C）：情報に対するアクセス権限を徹底して保護・管理すること（情報を外部に見せない、漏らさない）
完全性（I）：改ざんや過不足のない正確な情報が保持されている状態
可用性（A）：情報をいつでも使える状態を保持

本記事ではCIAのうちC（機密性）とI(完全性)についてのみを扱います。
インフラ設計ではAの部分はセキュリティ要件ではなく、可用性要件や信頼性要件など別物として扱われることが多いため、
別記事でまとめようと思います。

ではここからセキュリティ知識７選についてみていきましょう。

アクセス管理、権限管理（内部犯対策）

情報漏洩の原因のうち80%は人的原因によるものだそうです。
なので、内部犯(管理ミス、誤操作)対策を最重要なセキュリティ対策と捉える必要があります。
実際にシステム運用に携わっていると、
なんでこんなにガチガチなルールになっているんだろうと思うことがあると思いますが、理由はこんなところにありそうです。

最小権限の原則

必要以上の権限を与えない「最小権限の原則」という考え方があります。

最小権限の原則とは - IT用語辞典

最小権限の原則【最小特権の原則 / PoLP】とは、情報システム上のアクセス権限の運用についての原則の一つで、本来の目的に必要な最低限の権限しか与えないようにすること。障害や不正による被害を最小限に抑えることができる。システムの利用者や実行...

これは理想としてはあるものの、中々実現まではされていないのが現状かと思います。
本番環境（個人情報を扱っている環境は特に）の管理者権限が乱用されていると、セキュリティ監査での指摘事項となりえるため、
権限の設計を行う機会があった時にどこまで制御するかを意識・相談できると良いです。

権限設定の考え方(認証認可)

権限設定で知っておくべきなのは「認証」と「認可」とを分離して扱う考え方です。（最小権限の原則実現においても重要）

「認証」は「誰か」を判別し
「認可」は「どこまでを許可するか」を判別します。

ユーザ側からすると認証と認可は切り離せないものと認識されていると思いますが、
管理側からすると分離して扱った方が管理しやすいです。
Windowsであればユーザに対してパスワード制御などを行っていて、グループで権限を付与し、ユーザがグループに参加する形になっています。（グループ＝認可、ユーザ＝認証）

AWSのIAMというアクセス管理サービスの設定も認証（下記画像の信頼関係タブ）と認可（下記画像の許可タブ）に分離して設定できるようになっています。
（最初は混乱しましたが、この考え方を理解しておくと管理画面の構成が納得できます。）

シングルサインオン（SSO）

SSOとは複数のシステムのパスワード管理を一つにしてくれるものです。

セキュリティ対策は面倒というイメージがあると思いますが、SSOは運用効率が高まり且つセキュリティリスク低減につながる施策です。
複数の鍵（パスワードなど）を管理するよりも一つの鍵を管理するだけの方がセキュリティリスクが低くなるのは直感的に分かると思います。
又、他人のパスワードを聞いて作業するといった禁止行為もSSO環境であれば実施することが難しくなると思います。
Active Directory（Windows）がよく知られるSSOの実装技術だと思います。
(例えばドメイン参加したらファイルサーバアクセス時などにパスワード求められたりしなくなったりなど)

暗号化

暗号化は通信、ストレージ、ファイルの３つに分類できます。ひとつずつ見ていきます。

通信暗号化

通信暗号化は外部通信では必須ですが、暗号化には鍵や証明書の管理が必要になります。
通信暗号化については発展途上な部分もあり、歴史を軽くでも知っておいた方が話についていきやすいです。
暗号化通信はSSL、TLSという技術で実現されています。

総称してSSLと呼ばれることが多いですが、正確には両者は異なります。（下記の通りTLSの方が新しいです）
現時点では「TLS1.1」以前のバージョンではサーバとの通信において脆弱性があることが確認されています。

各サービスがTLS1.1の無効化はほぼ必須としてきていて、
有効になっている場合はサーバーやロードバランサー側での設定変更が必要になります。

主要ブラウザ（GoogleChromeやFireFoxなど）もTLS1.1で接続した場合に警告メッセージを出す対応を行ってきています。
古いOS、古いブラウザを利用しているとTLS1.2に対応しておらず、各サービスへのアクセスができなくなります。
(TLS1.1無効化対応はそういったユーザを切り捨てることになります。)

・PKI(公開鍵暗号基盤 Public Key Infrastructure)
PKIとは盗聴、改ざん、なりすましを防ぐための仕組みです。
通信暗号に用いられています。
この仕組みの理解が難しかったのですが、下記の記事はイメージしやすく解説されていてお勧めです。

【初心者】公開鍵暗号、認証局、デジタル署名をイメージで解説

SSL/TLS、電子商取引、本人認証などで、公開鍵暗号化方式、証明書や認証局などの用語が出てきます。ただし、これらは処理が複雑に見え、イメージが湧きにくいことがよくあります。ここで、公開鍵暗号方式、認証局、デジタル署名の理解を助ける私のイ

下記はAWSでSSL証明書を扱う場合には必読ですが、SSL証明書、ワイルドカード、証明書の種類についても簡単に解説したので参考になると思います。

AWSで利用するSSL証明書管理をIAMからACMに変更するべき理由 - Qiita

はじめに自分が担当しているシステムでELBに登録しているSSL証明書をIAM管理からACM管理に変更しました。AWS機能を利用してSSL証明書を管理する方法は２つあります。IAMを利用する方法…

上記に加えて、SAN（サブジェクトの別名）、マルチドメインなどの用語が理解できてると良いです。

ストレージ暗号化

ストレージ暗号化はハードディスクの性能向上により、
暗号化による性能影響の考慮が不要になってきています。
※ただし多少の性能影響はあるため、リリース済サービスの非暗号化ボリュームを変更する場合は注意が必要です

以前、AWSのEBSというストレージサービスの暗号化の性能影響をサポートに確認したことがありますが、
ほぼ影響ないと考えて問題ないと回答いただいたことがあります。

ストレージ暗号化も鍵管理が必要になりますが、
デフォルトでストレージ暗号化を行う方針の現場が多くなっているように感じます。

ストレージ暗号化を行っていると、正規のユーザーがストレージにアクセスした際は、データは復号された状態で表示され
第三者が不正にストレージにアクセスした場合はデータを復号できません。

ストレージ盗難された場合にも効果があります。

ファイル暗号化

保存された情報（文書）の窃取や漏洩に備え、ファイル暗号化を実施します。
zipファイルなどに固めておく形で実現します。
個人情報が入っているファイルに対して行うことが多いと感じます。

通信やストレージの暗号化は透過的なので、使う側は暗号化されていることを意識せずに利用可能ですが、
ファイル暗号化は使う側の解凍作業が必要になります。

ウイルス対策

マルウェア等に感染した内部端末からの攻撃に対する対策です。
理解した方が良いこととしては下記の記事に完全同意です。

ウイルス対策ソフト設計時の注意事項 - Qiita

ウイルス対策ソフト(アンチウイルス)の設計担当になった時はこんなところに注意しよう。ウイルス検知時の一次処理ソフトによって隔離・検疫・削除とか色々あるが、サーバだったらまずは隔離するのが無難。サーバには重要なファイルが大量に...

あとはリアルタイムスキャンは性能的に外部からのファイル流入があるディレクトリだけに絞ったりすることもあります。

サイバー攻撃手法

代表的な攻撃手法である「DDOS攻撃」と「クロスサイトスクリプティング」と「SQLインジェクション」について解説します。
（脆弱性診断を行うと必ずこの対策は取れているかが問われます）

DDOS攻撃

DOS攻撃は特定の機器（サーバーなど）に攻撃をしかけ、サービスを停止させようとする攻撃です。
対策を取っていないシステムでは攻撃を受けている間はサービス停止となる可能性があります。
DDOSは複数の機器を踏み台にして、一斉にDOS攻撃をしかけます。
このとき、踏み台として利用される機器には関連性がないため、攻撃を受けた側は犯人を特定しにくいことも特徴の一つです。
IoT機器約18万台からの大規模な攻撃を受けたという事例もあるようです。

クロスサイトスクリプティング

掲示板などユーザ入力でページ生成されるサイトで
JAVAScriptなどを入力することで、悪意のあるサイトに誘導する攻撃手法です。

デマニュースが表示されたり、Twitterで勝手に任意のテキストが投稿されるなどといった被害が発生しています。

SQLインジェクション

SQL文の組み立て方法に問題がある場合、攻撃によってデータベースの不正利用をまねく可能性があります。
対策を怠るとアカウント流出やクレジットカード情報漏洩などの大きな被害がでます。

参考までに攻撃例を記載しておきます。（ほぼ引用サイトからの引用です）

WebサイトのID欄に入力値として文字（例として”taro”）が入力され、SQLが実行された時



SELECT * FROM user WHERE id=‘taro’

となり、userという名前のテーブルから、IDがtaroのデータだけが出力されます。

では、SQLインジェクションを受けた場合はどうなるのでしょうか。以下に一例を示します。
＄IDの部分にtaroに続いて「’ or ‘A’=‘A」を注入（Injection)すると、

SELECT * FROM user WHERE id=‘taro’ or ‘A’=‘A’

となり、userの全ての情報を出力する

ということになります。

となります。

不正通信対策（WAF、IDS、IPS）

不正通信対策はWAF、IDS、IPSといった製品で行います。

IDS、IPS

不正アクセスを検知するのが「IDS」
検出と遮断をするのが「IPS」です。

IDS、IPSの製品導入はインフラエンジニアが対応することは少なく、
セキュリティエンジニアやネットワークエンジニアが対応することが多いです。
インフラエンジニアは現場のルールに従い、通信をIDS、IPS経由にするという設定を行うくらいです。

WAF

DDOSやWebアプリケーションの脆弱性を利用した攻撃（クロスサイトスクリプティング、SQLインジェクション）にはWAFで対策します。
外部公開しているWebサービスはWAF利用を必須としている現場もあります。
WAF導入もインフラエンジニアが対応することは少ない印象ですが、簡単な設定を行うことはあります。

ネットワーク分割

攻撃時の影響範囲を限定するため、システム間の通信、システム内の通信を分離又は制限することは必須です。
大きく分けてパブリックネットワーク（≒DMZ）、プライベートネットワークの2種類があるということを理解しておきましょう。

パブリックネットワークはインターネットからアクセス可能なネットワーク
プライベートネットワークはアクセス不可なネットワークです。

パブリックネットワークとプライベートネットワークに分けてセキュリティ方針は検討されます。

玄関のドアと各部屋のドアのセキュリティ方針は分けて考えるのと似ています。

パブリックネットワーク（≒DMZ）だけ暗号化やウイルス対策が必須とする現場があったり、
プライベートネットワークも暗号化必須とする現場もあります。
暗号化を利用すると復号処理によって処理速度低下したり、鍵管理の工数が発生しますが、
セキュリティとのトレードオフで方針検討されます。

脆弱性対策

ソフトウェアの脆弱性情報を収集し、対応を行う体制を整えておくことは重要です。

脆弱性の情報収集

脆弱性対策で定常的に行う必要がある業務は脆弱性の情報収集です。
情報収集方法は大きく分けて、下記の2パターンだと思います。

①週に一度など、ルールを決めて関連製品の脆弱性が無いかを確認することを運用化する
関連製品の脆弱性情報が記載されているサイトを定期的にチェックします。
週一で二時間くらい奪われるので可能な限り自動化しましょう。

②利用している製品を登録することで、該当する脆弱性があった場合に連絡をしてくれるサービス・ツールを利用
「脆弱性情報収集ツール」で検索すると色々出てきます。
現場で推奨されているツールがあればそれを利用します。

脆弱性情報はJVNというサイトに分かりやすくまとめられています。
JVNは日本のJPCERTとIPAが運営しています。
脆弱性にはCVE-YYYY-NNNNN(CVE-＜西暦年号＞-＜連番＞)という一意の番号が振られて管理されます。
(CVEはアメリカの団体が管理しています。)

脆弱性対策実施

影響が大きい脆弱性でなければ、半年に一度など定期的に脆弱性対策（ソフトウェアバージョンアップなど）を実施します。
ソフトウェアバージョンは即時で自動更新する機能もありますが、システム影響を考えると、即時更新されるリスクは大きいため、
あまり利用されていない印象です。

脆弱性診断

システムの新規構築時や運用の中で障害や機能追加などにより大きな修正が発生した場合には、脆弱性診断を実施するという運用が一般的です。

影響の大きい脆弱性発生時

影響の大きな脆弱性が発見された場合、早急に影響調査と対策を行う必要があります。
大きな会社だと「CVE-YYYY-NNNNNの対処を早急にお願いします。」などの形で全部署に対して一斉送信されます。
例）2021年に発生したlog4jの脆弱性についての調査
世界が震撼したLog4jの脆弱性　脚光を浴びたWebセキュリティ対策「WAF」の真価　“現場の負荷”を減らす切り札か？