2021年までの仕事を振り返る
はじめに
最近は社内でもはじめましての人が増えたり、社外の人と話す機会も増えてきたけどいまいち何やってる人なの？という説明しづらさが発生してたので、年末という区切りの良いタイミングで自分がやってきたことを一度まとめてみたい。
ざっくり言うと、2020年頃からそれまで所属していたSREチームから半分軸足をずらし、Securityチームにも所属して主にクラウドセキュリティ系の施策を進めていた。
この記事では、具体的なタスクを振り返りつつ学んだことなどを振り返ってみる。だいたい時系列順です。
やってたこと
Bridgecrew対応
Bridgecrew は out-of-the-box なセキュリティポリシー群によるIaCコードレビュー、および実体のリソースまでスキャンしてポリシー違反をチェック (CSPM) してくれるSaaS。このスキャン結果を優先度高いものから要不要のトリアージをしつつ、順に潰していくという対応を進めていた。
Bridgecrewのポリシーは CIS Benchmarks などの複数の一般的なセキュリティポリシーが元ネタになっており、こういった各種ベースラインアプローチの考え方に慣れることができたこと、判断のブレがない指標は監査がやりやすく、自動化がしやすいといった性質が理解できたこと、逆にそのアプローチの限界 ( アーキテクチャレベルのプラクティスなどは指摘しづらい ) も知れた。
いわゆるクラウドセキュリティの防御における勘所もわかってきたり、ROI考えながら自分で要不要の判断が徐々に下せるようになってきたのは成長した点。
EC2 Auto Patcher
AWS Systems Manager Patch Manager を利用してEC2インスタンスのパッチを自動で適用するやつをリリースした。( カーネルライブパッチ も有効化 ) モノとしてはうまく動いており、主に社内ツール系でスタンドアロンで立ってるEC2なんかには非常に有用だった。ものの、オートスケールするクラスターとは正直相性は悪かったりもする。( ゴールデンイメージに変更を入れ…るの ? )
そこにEC2があるから、というだけでそのままパッチを当てることに正面から向き合うよりは、やはり可能な限りコンテナリフトして交換容易性を高めることでパッチを当てやすくする、さらにできれば Fargate とか Lambda とか使ってホストOS部分の関心事を減らしていく (責任共有モデルのManaged By Customerな部分をへらす) とか、自社開発で無いものであればSaaS版に乗り換えてしまうのが正しいアプローチな気はしてきている。
この辺りまでの学びから、チェックリスト的な指摘に対してそのまま対応してしまうとキリがないことに気づき、モダンなシステムに適合するとどうなるのかをうまく翻訳したり、管理するものを減らしたり、運用上の優位性も両獲りできるようなアプローチで解決していくのが望ましいことを肌身で理解し始める。以降のタスクではそういった観点も盛り込んで進めているものが多い。
( とはいえ結局、力技でやってくしかない部分も現実的には絶対あるのでバランスではある、やるしかないことは放置せずやるしかない…という強い気持ちも同じぐらい大事 )
AWS Organizationsの本格活用開始 & AWS SSOの導入
2月頃にAWS SSO系のリソースがTerraformで書けるようになったので、移行した。 2019年頃 に作られた仕組みでは割とヘビーなterraform moduleで管理していたけど、できるだけOrganizations/AWS SSOのプラクティスに寄せることで多くのリソースを捨てることができたり、以前と比べて AWSアカウントのセットアップや権限アサインが楽になった。(ほぼ1PRでOktaからログインできるAWSアカウントが立ち上がることや、権限アサインがTerraformで全部完結する)
こういった基盤の部分では、下手に自社独自の差分を作らずしっかりベストプラクティスに追従していくことで機能アップデートの恩恵を享受しやすくするのが本当に大事と思う ( 参考：無駄にGAFAの逆をいくな…というお話 )
AWS IAMのセキュア化
こちらに詳しく書いた → AWS IAM セキュア化の取り組み
踏み台サーバの廃棄 & コンテナ化
こちらに詳しく書いた → 踏み台EC2を廃止してSession Manager接続に置き換えました
GCPのリソース階層 / IAM整理
Evolution of Eureka’s Data Platform や オンライン機械学習サービスとしてGCP Vertex AIのMLOpsを導入した話 などでも触れられている通り、今年は社内でGCPの利用用途が再定義され&拡大する年だった。…というわけでやっていきが発生した。権限の下位リソースへの継承があったり、Terraformの書き味の細かい差分などはあるので丸っきりそのままではないが、基本的にはAWS Organizationの整理やIAMのセキュア化と似たようなことをGCPの方言に当てはめて進めるもの。AWS普段触ってる人のために、AWSの考え方をGCPに当てはめると？みたいな公式の記事もいくつかあって面白いし便利なので、このあたりはいつか記事を書いて紹介したい。
Google Workspace セキュリティチェックリスト に基づくGSuiteの設定診断
GCPのIAMはGoogle Workspaceのアカウントにそのまま権限が付く形になるため、いくらGCP側のセキュリティを強固にしていたとしてもGoogle Workspace側がガバいと意味がないので、 Google Workspaceのセキュリティチェックリスト を元にしてMIS(情シス)チームと現在の設定について確認やディスカッションを行った。
この辺りで、会社のID管理の根本の部分固めるの大事だなーとか、クラウド以外のSaaSにもどう気を配っていくべきかなー(SaaSOps？)ということも何となく意識し始める。
その他
監査対応のサポート / AWS WAFの運用 / Payment APIのECS化 / Athenaのログテーブル整備 / S3などのリソース棚卸し / 各種インシデント対応リード / その他普通のSRE業、などなどなどもやっていた。
( 他にも色々やった気もするけど、詳細は書けないものもあるので割愛
資格試験
自分が何ができるのかを、そろそろ客観性のある形でアピールする必要があると感じてきたことや、なんか周りで流行ってたので色々受験してみた。AWS SAA (10月受験)、基本情報処理技術者試験 (11月受験)、情報セキュリティマネジメント試験 (12月受験) など取得した。
受験してみての感想としては、ボトムアップで学んできたことを網羅的 & 体系的に整理し直せる点だったり、無理やり申し込んでおくことで強制的に勉強しやすくなるっていうのは良いなと思った。とはいえ現状の知識から大幅ストレッチな資格を取ったという感じもなかったので、来年は勉強のリズムを崩さず、より上位の資格にもいくつかチャレンジして新しい知識を入れていきたい。
外部発信の強化
これも資格と似たようなモチベで、仕事ネタでmediumでブログを書くようにした。
細かいのは他にも書いてたけど、特に気合い入れて書いたこの2記事に関しては、拡散していただいた皆さんのおかげではてブもたくさん貰うことができ、手応えを感じた。何か頭の中でまとまったものがあるから書く、ではなく、書き出す過程で考えもまとまるということがわかったのでぼちぼちやっていきたいと思う。
来年やりたいこと
といった取り組みをしてきて、来年のやっていきについて考える。
トップダウンのポリシーとボトムアップの取り組みの接続
得意なAWS周りのバックグラウンドを活かして、ハンズオンな取り組みやベストプラクティスの導入を進め、リスクを低減しつつ徐々にこの分野の肌感も付けていく、というのは個人としてはかなり勉強になってよかった。一方でリスク評価の厳密性とかは走り出しの時点では捨てていて、定性的に重大度が大きいものであったり、手が付きやすいものから対応をすすめてきた部分はある。
この進め方については社内でよくフィードバックをもらうこともあった。個人的にはまず土台を作らないとどうにもならないし、先に手を動かしてみなければ分かるものも分からないと思っていたので、その辺りは意図して後回しにしていた側面もあるが、ある程度取り組みが進んできた今では、確かにトップダウンかつ網羅性のある取り組み ( ISMSとか？ ) との統合 / 接続をしていく必要があるなと感じている。
とはいえ、トップダウンアプローチで進めた時に各プラットフォームの細かいベストプラクティスという解像度だったり、日々めまぐるしく変わる状況についていけるものなのかまだよくわかってない。最上段のセキュリティポリシーから、コードの1行、ひとつのConfigに至るまでが解像度を落とさず接続されている「血の通った」状態に持っていくのが理想的な状態なんだろうなと思っている。やっていきたい。勉強せな。
インプットの質を変化させる & 言語化力、伝達力を磨く
インプットするのは当然として、アラカルト的に学んでいるだけだと、応用力がなかなか付かなかったり、判断精度が下がると感じてきたので、最近は情報収集のやり方も、一定のテーマに沿って広く事例を調査して、帰納的にこうだな、という本質を導けるようなメモのとり方をするとか、逆に注力部分以外は情報を遮断してみるとか、色々と試行錯誤してみている。あるいは資格試験のような形で体系的にどんどん知識を吸収する、というのも有効そうだとわかった。
そういった確固たるインプットに裏付けされた形で、「この問題の背景にはこういうストーリーがあって、我々はこれをこういった重要度のリスクだと捉えている。だからこれをやりたいから承認してくれ or あなたにやってもらいたい」という話をシンプルにまとめて語れるようにならないと、いくら判断自体が正しくても、やるべきことを他に広げてスケールさせる動きはムズカシイな、というのは最近思うところ。
また、「人の脆弱性」がセキュリティ最大のリスク、とも言われるので、当然エンジニアでないロールの人たちも含めて自分ごと化してもらう必要があると思っている。そういった意味でもシンプルに翻訳し、言語化して伝えていく力、大事な気がしている。
自分の軸を今後どこに置いていく？
これまでは あくまで SRE / インフラエンジニア という立場からセキュリティの堅牢化に取り組んできたものの、あくまで注力分野の1つでしかないという点において動きづらさがあったり、自分の管轄領域 (AWS / GCP) 以外に手を伸ばしづらいという感覚があった。
自分が働くモチベーションとして、まず事業や組織に共感していて、そこに自分が(手段は問わず)どう貢献できるか？という気持ちが強い。「事業会社のセキュリティを強化する」という広い視点で考えたときに、今時点での自分の技術領域だけに閉じず、もっと Corporate Security 的な ( ニュアンス合ってるんだろうか？) 領域まで見て対応する必要がありそうで、それをやりたいという思いも生じてきた。ので先述のトップダウンな … といった話とも合わせて、SREという概念にこだわりすぎず、来年はもっとそういう動きができるようにしたい。
