ここ数年、アジリティとセキュリティ(あるいはガバナンス)の両立について考える機会が多い。伝統的で規模の大きい企業にありがちな傾向として、セキュリティやガバナンスを確保するためにはシステムの開発/運用が鈍重、高コスト、不自由になったとしても已む無しとする思想がしばしば見受けられる。結果として例えば簡単な仮想サーバ１つを用意するだけでも数ヶ月の納期と膨大な工数を要するとか、世の中で当たり前に活用されている技術やプロセスが許可されない/導入に非現実的な手続きを要求されるといった状況が生まれる。
確かにシステムの安全性を適切にコントロールすることは重要である一方で、論理的に考えれば「セキュリティのためのビジネス」ではなく「ビジネスのためのセキュリティ」なのだから、セキュリティを確保するためにビジネスの成功が妨げられてしまっては本末転倒に思える。しかし実際には「セキュリティのためなので仕方がない」とか「文句を言うやつはセキュリティの何たるかを理解していない」といった具合にセキュリティという言葉が何でも叩ける便利な棒のように扱われている状況をしばしば目にする。そういった態度の根底には本質的にビジネスの成功に対する無関心や、自身の職責を限定してその範囲の中で減点されないように動こうとする官僚主義的な姿勢が横たわっていて、邪悪であるとすら感じる。
そもそも、情報セキュリティを確保する手段として、セキュリティ以外のコンテクストでメリットがある仕組みを「禁止」することは最も安易で稚拙な手段であって、その戦略を是とするならば究極的には「情報システムを使わない」のが最も安全であることになる。パソコンやサーバ機器を捨てて、紙とペンで仕事をしたら良いのだ。いやだめだ、それでは本質的には「情報」の安全性を確保できていない。事業活動を全部やめて「何もしない」のが最も安全なのだ。”セキュリティ至上主義者”はそれで満足するかもしれないが、残念ながら早晩職を失うことだろう。
正しいセキュリティ、本当に高度なセキュリティというのはビジネスをサポートするものであって、柔軟性を確保しつつも適切なコントロールを維持する方法をデザインすることがその責務であるはずだ。そのために担当者は前例踏襲や形式的な手順、目の前のセキュリティアプライアンスやツールの表層的な仕様や運用に固執するのではなく、ビジネスやユーザの声に耳を傾け、セキュリティに関わる技術を正しく理解し、DevSecOpsやPolicy as Code等のパラダイムを学び、プロセスやプラットフォームの改善に取り組むべきなのだ。それにも関わらず高度な職責を果たすだけの能力と意思がないことを棚に上げて、「失敗しない」方法を墨守し続け、ビジネスに不便を強いるのは褒められたことではない。「セキュリティを確保するための」コストや工数についても、それが高くて遅いことは「セキュリティの問題(だから仕方ない)」ではなく「能力とメカニズムの問題」であって、自分自身の限界を示していることを内省するべきだ。
勘違いして欲しくない点として、セキュリティ担当者に金を払うなと言っているわけではない。むしろもっと払うべきだと信じている。労働集約的なワークフローで低レベルなアウトプットを出すのではなく、その数人分の予算で優秀な技術者を1人雇ったほうが遥かにスケーラブルかつ高度なメカニズムを構築できるはずだ。また、セキュリティを軽んじていいと言っているわけでもない。むしろもっと真剣に考えるべきだと信じている。古典的企業における”セキュリティ”は時に技術的に妥当でなかったり古くなっていたりして、逆にセキュリティリスクを増大させているケースが少なくない。例えば境界型セキュリティへの信仰や、「危険な」新しい技術を避けて古い技術やソフトウェアバージョンを使い続けたり、独自実装しているような事例がそうだ。こうした傾向は技術から目を背け、既存のポリシーや手続きを所与のものとして捉える態度に根ざしている。
ただ、これらは企業のセキュリティ担当者個人の能力や人格の問題ではなく、組織的な構造的問題がいくつも根底にあり、複雑に絡み合っている。言い換えるなら、経営が責任を問われるべき問題だということだ。
まずもって、大組織において組織は職責ごとに分離され、ビジネスに責任を持つ部署とシステムに責任を持つ部署、後者の中でも開発に責任を持つ部署、基盤に責任を持つ部署、運用に責任を持つ部署、セキュリティに責任を持つ部署...といった具合に縦割りであることが多く、セキュリティ担当者はおろか、開発や運用を担う部門すらシステムが担うビジネスの成功に責任を負っていないケースが多い。そういった組織では如何に当初のスケジュール通りにリリースが出来たかや、如何に障害を起こさなかったかといったことだけが評価指標になっていて、「いかに素晴らしい仕組みを作ったか」「いかにビジネスに貢献したか」は全くシステム部門の評価対象になっていない状況をしばしば見かける。
更に言えばエンジニアリングに関わる実務はそれぞれの部門に紐づくSIerが担っている場合も少なくないが、そういった人々は究極的には自分たちが作ったサービスが誰にも使われず一切の価値を産まなかったとしても、計画通りの工数分稼働すれば自社の収益となるしそれが仕事なので、顧客ビジネスの成功に対する組織的なモチベーションが希薄であることが多い。従って、既存のルールや仕組みが非効率で非論理的であったとしてもそれを改善するモチベーションが働きづらい。(もちろん個人、個別PJ、個社レベルでは意思とメカニズムの工夫によってそうではない事例も多数ある)
また、非効率な”セキュリティ”の根拠が組織規模、時には業界規模のポリシーや信仰に根ざしているため、個人や個々のチームレベルでは覆すことが難しいケースも少なくない。例えば金融業界には「運開分離」、つまり開発担当者と運用担当者の職務を分離するべきであるとするパラダイムがある。開発担当と運用担当の権限を分離することで開発担当者が本番環境のプログラムやデータを改竄できなくなりセキュリティが高まるといった趣旨の思想だ。これは明らかにDevOpsに逆行する考え方で、実際様々な現場で機動的な開発/運用の連携、一体化の試みが「運開分離」の名の下に拒絶されがちだ。
DevOpsのメリットが損なわれることを脇においても、そもそも「運開分離」が本質的なセキュリティの確保に繋がる手段なのか(例えば運用担当が不正を働くケースは考慮しないのか？)は疑問である。また、目的はリスクの管理と対応であって「運開分離」はその一手段に過ぎないのだから、対案となるより高度なセキュリティ確保、例えば開発組織内でのきめ細やかな権限管理やゼロトラスト、ガードレールの敷設などによって同じ目的を達することは出来るはずだ。実際、金融業界の外の、「運開分離」が当たり前ではない企業のシステムは危険でいっぱいなのかといえば必ずしもそうではなく、違う方法で適切なコントロールが実施されているのが普通だ。
これを改めるのが難しい理由の１つは、こうした方針は個別企業単位で決めているものではなく、金融庁やFISC(金融情報システムセンター)などのガイドラインによって業界全体で共有、指導されているものだからだ。例えば、金融庁の証券検査マニュアルより、「システムリスク管理態勢の確認検査用チェックリスト」には以下の記載がある。
個人のミス及び悪意を持った行為を排除するため、システム開発部門と運用部門の分離分担を行っているか。ただし、要員数の制約から業務部門を開発部門と運用部門に明確に分離することが困難な場合には、開発担当と運用担当を定期的にローテーションすること等により相互牽制を図っているか。なお、上記に関わらず、ＥＵＣ（エンドユーザーコンピューティング）等開発と運用の組織的分離が困難なシステムについては、コンプライアンス部門等により牽制を図っているか。
https://www.fsa.go.jp/news/newsj/syouken/manual_1306/syouken_19.pdf
社内のポリシーやルールですら改めるのが難しいのに、国や業界レベルでこうした方針がアナウンスされているようでは、並の担当者がこれに立ち向かうのはほぼ不可能に近い。仮に自社のセキュリティ部門を論理的に説得できたとしても「でも運開分離は業界の掟なので。。。」といった具合に伝家の宝刀を抜かれてしまったら手も足も出ないだろう。本来は手段、あるいはポリシーの1つにすぎないはずの「運開分離」を実践することそれ自体が「セキュリティ」そのものに直結しているかのような認識はしばしば見受けられ、それどころか「運開分離に異を唱える」=「こいつはセキュリティを理解していない」と糾弾されるような状況は本当に嘆かわしい。
論理的な正しさではなく前例踏襲的なセキュリティ施策が重んじられるその他の背景として、大企業の総合職におけるジョブローテーションも関わっていそうな気がする。一部の企業のシステム部門やセキュリティの部門には、ジョブローテーションによって担当する職務はおろかIT全般にすら何らスキルや経験を持たない人間が配属される例が珍しくない。数週間前まで法人営業をやっていたような人物が、ある日突然、組織的な情報セキュリティの意思決定者になるわけだ。当然ITやセキュリティのことなど分かろうはずもなく、そんな人物が縋ることが出来る最高のリソースは、前任者が自身の職責をどのように「問題なく」果たしていたかという前例データとなる。結果としてその合理性や改善の余地を検討することなく、技術をブラックボックス的に扱い、現場から目を背け、ただ同じことを繰り返すことが最も妥当で安全な道になってしまいがちなのではないかと思う。一部の企業に見られる、他社事例に非常に拘る傾向もここから来ているのではないだろうか。
それらの根幹にある病巣は、究極的には企業としての危機感のなさに帰結するのだと思う。本質的ではないセキュリティに固執したり、低レベルな方法でセキュリティを確保することでビジネスの成功を阻害していられるのは、詰まるところ企業全体として余裕があるか、余裕があると信じているのでそうしたオーバヘッドを受け入れることが出来るからだろう。本当に困っている企業、少しでも速く事業を成長させなければ経営が危ういような企業がそんな”道楽”に付き合っていられるだろうか？詰まるところ、どれだけ非効率/価値を産まない仕事をしていたとしても当面企業も自身の雇用も安泰で、無難に日々をやり過ごしていれば問題ないと信じている/あるいはそれが事実であるから必死さがないのではないか。
実際問題、一部業界のトップ企業は圧倒的な資本の積み上げによって、後発企業がいかにイノベーティブに頑張っても向こう10～20年は到底追い越せなさそうな差をつけているのも事実ではある。とはいえ各業界で国内の後発企業群も猛追しているし、世界に目を向ければ競争相手、あるいは追いかけるべき企業も存在しているはずだ。企業として何処を目指すか、なにをもって「安心」と考えるかは結局は経営と株主が判断するべき問題なので、まずはそのレベルの人々が現状を認識し、意識改革する必要があるのではないだろうか。業界団体や監督省庁についても同じで、国家レベルで業界の競争力を真剣に考えるならば「いかに失敗しないか」だけではなく、その競争力についても目を光らせ、後押ししていくべきだと思う。(ただ、古典的日本企業の複雑怪奇な特徴として、一見すると上意下達に見えて、実はトップダウンなリーダシップを効かせるのが難しく、施策が現場に骨抜きにされやすい傾向もある気がするが。。。）
そして古典的日本企業の変革に期待するのと同じぐらい、新興企業やネット生まれの企業が成長して業界を変えていくことを願っていて、本当に微力だが自分もその両方に貢献したいと思って生きている。
ただ、これを読んでいる人の多くは業界の重鎮でも大株主でも経営者でもなく、市井の善良なエンジニアだと思うので、「オレにはできることねーじゃねーか、、、」と絶望的な気持ちになったかもしれない。セキュリティの文脈からは少し逸れる内容だが、そんなみなさんにオススメの書籍を紹介して結びとする。
www.oreilly.co.jp
上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。
重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。
組織で必要とされる変化を、エンジニアが行動することで実現する本書は、ソフトウェアシステムをよりよく開発運用したいエンジニア必携の一冊です。
