IT業界では、セキュリティーのニュースを見ない日はないと言えるほどセキュリティーは重要な課題です。どこの会社もセキュリティ対策に重点を置いてシステムの開発・運用を行わなければなりません。
ただ、セキュリティ対策を強化するとエンジニアの生産性に影響がないとは言えず、むしろ生産性的にはマイナスの効果もあり得ます。自分はセキュリティ対策の担当もしながらエンジニアとしても働いているので、自分が関わった対策の影響で、自分のエンジニアの仕事に手間が増えたり以前より時間がかかってしまった経験がよくあります。
そのあたりの経験などをまとめてみました。
セキュリティパッチ
システム運用をしていると、セキュリティパッチ関係のタスクはほぼ毎週、毎日のことで毎日のように新しいCVEが出され運用しているシステムでパッチをする必要が出てきます。
CVEの詳細は以下を参考にしてください。
すごくシンプルなシステムでも、サーバー、ロードバランサー、ネットワークデバイス、エンジニアが使用するラップトップなど、これだけでも４－５個のITデバイスがありそれぞれに多くのソフトウェア、ライブラリーが使用されていています。それらすべてが何らかのCVEの対象になりうるわけで、日々出されるCVEの量は膨大です。
どれが自分のシステムに該当するかを見つけるのことは手動ではほぼ不可能で、Tenable.ioのようなスキャンシステムを使用して自動検知できるようにしなければとても無理です。
少し大きなシステムでクラウドとかで運用してKubernetesなど使うと、CVEの対象はさらに多くなりコンテナのCVEをスキャンするシステムが必要になってきたりもします。
セキュリティーの部署からすればこれらのツールを利用して、社全体でどれほどのインパクトがあってどの部署が責任をもってCVEの対応をする必要があるか把握しなければなりません。
CVEにはスコアがあって脆弱性の危険度によってレーティングされています。これも一見CVEのスコアをもとに重要性を決めればいいように見えますが、対象のコンポーネントがどのように使用されているかによって優先順位も決めなければなりません。
例えば同じCVEでもインターネットにつながっているロードバランサーと社内で使用しているものを比較した場合、コンポーネントの脆弱性、危険性は変わりませんが、優先順位としてはインターネットにつながっているロードバランサーのほうが外部からの攻撃にまず対処できます。セキュリティ的には社内も同様に対処すべきですが、攻撃のもととなるソースは外部のほうがはるかに多いですし社内の場合はある程度コントロールができると思います。
エンジニアとしては毎日のようにどのような脆弱性が発見されて、緊急に対処するべきなのか数日・数週間の余裕があるのか、即対処する場合はどのようにテストを進めるかなどCVEによって決めて進める必要があります。
基本的なOSのパッチなどはあらかじめ手順を決めて、定期的にパッチを実行したりすることによってすべてのCVEを把握して行う必要はなくなります。
また、再起動が必要なパッチの場合は、システムのダウンタイムが必要なのか、その場合は関係部署との調整、顧客への通達など多くのプロセスをあらかじめ決めておかないとlog4jのような緊急のCVEが出たときに即座に対応できなくなります。
このようにのセキュリティパッチのタスクには、多くの時間を割く必要がありまた緊急度によっては進行中のプロジェクトやタスクを一旦すべてとめて対応をする必要もあります。負担を軽減するために、できるだけセキュリティパッチの自動化を進め、手動作業を減らさないとエンジニアとしてのほかの仕事の時間が無くなってしまいます。
ランサムウェア対策
ランサムウェアはシステムのデータなどを暗号化し、システム自体を使用できなくするような攻撃です。そのうえでランサム（身代金）を要求して、支払われた場合に復号鍵が渡されて暗号化を解除できるようになります。中には、Ransomware as a Service (RaaS)といったサービスまで存在し、顧客がサービスを利用してターゲットにしたい企業・システムなどから受け取った身代金から成功報酬を受け取るといった形で提供されています。
システム運用者としては、ランサムウェアにかからないため以下のような対策をして攻撃ベクトルを減らさないといけません。
- 前述のパッチなどを頻繁に行いシステムの脆弱性をできるだけなくす
- アクセス経路を必要最小限にする
- システムの監視をして不自然な動きがないか見極める
- ログを採取して、不正アクセスの検知
これはいくつかの例で、それ以外にも多くの対策が必要です。ただこれだけやっていても攻撃を受けて暗号化されてしまうこともあるかもしれません。
その場合重要になるのがバックアップです。ランサムウェア対策としてのバックアップは、取ったバックアップが同じシステムからアクセスできてはバックアップも暗号化されてしまいます。それを避けるために隔離されたネットワーク、できれば物理的に離れたデータセンターに置いておく必要があります。そうしておくとディザスタリカバリとしても使用できます。またバックアップ自体が上書きできるようでは、これもあまり意味がないかもしれません。できれば一度とったバックアップは上書き不可の状態で一定期間保存でいるのが望ましいです。
このようにバックアップだけでも、数日分から数か月分保存する必要があり、そのための予算も多く必要です。エンジニアとしてできるだけ予算のかからないバックアップ方法（クラウドストレージのArchive機能など）を見つける必要があります。
OSハードニング
ハードニングはシステムを堅牢化することで、アクセス権限を下げたり、アクセス方法を制限したり、パスワードを定期的に変更させたりなど、多くの制限をOSにかけることでシステムを堅牢化しセキュリティーを強化するものです。とくにパブリッククラウドを使っていると提供されているOSのイメージには、セキュリティパッチやハードニングがされていない状態で提供されていて、基本的にはユーザの責任で行う必要があります。
エンジニアとしては提供されているイメージをもとに、使用するシステムの要件に沿って堅牢化されたイメージを制作しVMをビルドした時点では、脆弱性が最小限のものである必要があります。たとえば、毎日もしくは毎週イメージを更新して、パッチがすべて当たっている状態で、ハードニングを行うスクリプトを実行して、アクセス制限や不必要なパッケージを使えなくするなどして初めてシステム用のVMに使えるようにします。
最近あった例では、OSのBashのコマンド履歴が残らなくなるように強化されているシステムがありました。もしもの時に、どのようなコマンドを管理者が使ったか簡単にわからなくするためと思われます。エンジニアとしてはこれをされると、使用するコマンドの細かいSyntaxを全て記憶するかいちいち調べる必要あり、またすべてをタイプする必要があるので相当面倒です。小さな例ですが、これは生産性にはかなり影響があり、特にシステムで障害があるなど緊急性のある場合は過去のコマンド履歴があると相当助かります。
特権アクセス管理システム（PAM）
特権アクセス管理システムは、特権アクセス（Privileged Access）を管理するシステムで、システム運用者などいわるるRootアクセスなどを行う方法を一元管理するシステムです。
特権アクセス管理システムの設定次第で、アクセスの制限を色々とできます。ユーザの管理程度でアクセスする方法は普段使用してるラップトップから行えるようにできたり、より強固のする場合は専用のデバイスからのみ特権アクセス管理システムにアクセス出来ることも可能です。普段使用しているラップトップとは別に、システム管理専用のより堅牢化されたラップトップからしかアクセス出来ず、それぞれ使い分ける必要が出てきたりします。考え方としては、普段のラップトップは、インターネットにもアクセスしているし何かのダウンロードもしているので信用度が低いということです。万が一、マルウェアに感染していても気づかず、重要なシステムにアクセスして被害を拡大する可能性があります。それに対して管理専用ラップトップの場合、インターネットにアクセス出来なかったり、必要なソフトは一括管理されて安全性が確認されたもののみ提供されて、より攻撃ベクトルが減らされている状態です。
エンジニアとしてはこれは相当面倒で、単純なファイルのコピーやコマンドの実行もバイナリがなくてできないことも多くあります。セキュリティ的には一元管理されていて効率が良いように見えますが、実務的には負担はかなり大きくなります。
当然、特権アクセス管理システム自体が最大の攻撃対象となるわけで、ここが脆弱性を持っていればそれを通してアクセスを管理しているシステム全てに影響を及ぼします。もし特権アクセス管理システムがダウンした場合はエンジニアはシステムアクセスできず仕事なりません。ですので、特権アクセス管理システムの運用は細心の注意とサポート体制が必要です。
オンライン会議
少しシステム運用からは異なりますが、先日ドイツ軍のオンライン会議が傍受されるといったニュースがありました。
その時は一般のウェブ会議アプリで会議を行っていて、それで傍受されたようです。軍なら本来専用のネットワークなどセキュリティの強化された物を持っていると思います。
一般の企業でも、社員から何らかの企業秘密が漏れたり、社員のラップトップを通してランサムに感染したりするのを防ぐためにアクセスの管理、MFAの導入、特権アクセス管理システムの導入などを行いセキュリティ強化を進める必要があります。
これは会社としても必要で、顧客に向けたメッセージとしてセキュリティを強化してることは重要です。ただ、そのためには多くの予算を割く必要があります。攻撃方法は日々進化しているのでそれに対処できる社員の教育も重要です。
しかしながら、エンジニア的には普段の仕事で多くの制限がかかり、技術的に不可能になったり、本来より多くの時間を費やす必要も出てきます。これは言い換えると、そのまま生産性や人件費につながります。セキュリティ強化を進める場合はこれらを考慮して行わないと、プロジェクトで提供しているサービスの低下にもつながりかねません。
まとめ
会社それぞれで考え方や、セキュリティポリシーも異なるので対処方法も異なると思います。ただ攻撃する側からすると、ターゲットの会社のことなど関係なく目的を達成できるかどうかだけが重要なのでしょう。
セキュリティへの考え方は人それぞれで、全員が納得できるポリシーなど作れないと思います。ですので、会社であれば権限を与えられたセキュリティ専用の部門がポリシーを決め、それが社内ルールとしてしっかり実行できる担当者を部署やプロジェクトで作る必要があるかと思います。それぞれのプロジェクトでポリシーを考えていると、必ずどこかに穴ができ攻撃ベクトルの多いシステムとそうでないシステムができてしまいます。
以上、いくつかの例を挙げてセキュリティ強化とエンジニアへの影響を考えてみました。