はじめに
こんにちは！
今回はセキュリティに関する記事を書きました。
どなたかの役に立てばと思います！
さて、クラウドサービスの普及に伴い、多くの企業がその恩恵を受けていますね。
実際、クラウドサービスは簡単に利用できるので、エンジニアとしても利便性を感じます。
しかし、利便性の裏にはセキュリティリスクが潜んでおり、これらを軽視すると重大なインシデントを招く可能性があります。
私の会社では、クラウド基盤を活用したシステムの開発や運用を行う中で、いくつかの「ヒヤリとした」体験を共有する機会がありました。
これらは大事に至る前に対応できたものの、日々の運用で見落としがちなポイントが原因でした。
この記事では、実際に経験したクラウドセキュリティの「ヒヤリ・ハット」事例を3つご紹介します。
同じような状況に遭遇する前に、あなたのシステムで必要な対策を検討するきっかけになれば幸いです。
ヒヤリ・ハットとは
「ヒヤリ・ハット」とは、大きな事故や問題には至らなかったものの、「ひやり」としたり「はっと」した経験のことを指します。
この言葉は、主に医療や製造業で使われてきました。
近年ではIT業界でもリスク管理の観点から注目されているようです。
こういった事例は、重大な問題を引き起こす「予兆」として捉えることができます。
そのため、早期に対応することで大きな被害を防ぐことが可能です。
つまり、「ヒヤリ・ハット」を見逃さずに改善につなげることが、リスク管理の第一歩です。
体験談：ヒヤリ・ハット事例3選
1. ベンダのアカウントが残っている😱
あるプロジェクトで、外部ベンダにシステムの開発を依頼しました。
ベンダ専用のアカウントを作成し、開発期間中は適切に運用されていました。
しかし、開発完了後もそのアカウントが削除されずに残っていたのです。
数カ月後、検証アカウントの整理を行った際、そのアカウントがパスワード変更されることなくそのまま残っていることが発覚しました。
アクセスログを確認したところ、幸い、悪用された様子はありませんでした。
しかしこれが、仮に不正アクセスが発生していたら大きな被害につながっていた可能性があります。
対策
アカウントの定期棚卸しを実施することにしました。
特にそれぞれのアカウントを人に紐づけるようにし、その人がプロジェクトにいるかいないかでアカウントの要否を判断するように管理しました。
これにより、使用が終了したアカウントは即時削除されるようにすることができました。
また、アカウントの利用状況を監視し、異常があればSlackに通知する仕組みを導入しました。
2. AWSサーバの踏み台ポートがベンダの固定IPに対して開きっぱなし😱😱
開発中のAWS環境で、外部ベンダの固定IPに対して踏み台サーバのSSHポートが開かれたままになっていました。
本番リリース後もこの設定が残っていたことに気づいたのは、他の作業中に偶然設定を確認したときです。
さらに問題だったのは、この踏み台サーバが本番環境と検証環境の両方に接続可能で、アプリケーションサーバやバッチサーバにもアクセスできる状態だったこと。万が一、固定IPからのアクセスが不正に使われた場合、全環境に被害が広がる危険がありました。
対策
まず、不要なポートは閉じ、ネットワーク制限を厳格化しました。
AWSはこの辺りの設定もコンソールから簡単に行えるので、なぜ構築を担当したインフラエンジニアはその考慮ができていなかったのか...
と愚痴を言い始めると止まらなくなってしまします。
また、ゼロトラストモデルを採用し、環境ごとにアクセス経路を分離しました。
当社の他PJでは、踏み台サーバを環境で分離させているケースが多いので、そのようにすることも考えたのですが、
そもそも環境ごとにAWSアカウントを分離し、踏み台経由ではなく、SessionManager経由でアプリサーバへアクセスできるようにしました。
一方、DBは、開発者各自慣れたGUIツールがあると思うので、こちらだけ踏み台経由としましたが、そもそもAWSアカウントを切り離したため、踏み台サーバも自ずと分離する形になりました。
3. 全ての権限が付与されたDBアカウントが存在する😱😱😱
ある日、開発チームから「一部のデータベース操作に権限不足エラーが発生している」との報告がありました。
これは、案件にジョインしてまもないチームメンバーが、データを書き換える際、リードオンリーユーザでログインしていたためでした。
ただ、この調査の過程で、特定のDBアカウントが全ての権限を保持していることが判明しました。
このアカウントは本来、データ解析用に作成されたものでしたが、開発時の利便性を優先して設定が甘くなっていました。
内部関係者が悪用する可能性や、万が一このアカウントが漏洩した場合のリスクを考えると、非常に危険な状態でした。
すぐにこのアカウントの権限を最低限に抑える対応を行いましたが、問題発覚の遅れがインシデントを引き起こしかねない状況でした。
対策
最小権限の原則を厳守し、不要な権限は付与しないというルールを徹底しました。
新規ユーザー追加時には、権限設定をレビューし、不適切な設定を早期に修正するという対策も取り入れました。
また、もし万が一があった時のためにアカウントごとの操作ログを詳細に記録し、異常を検知できる仕組みも構築しました。
結論
クラウドセキュリティの運用においては、ついつい見落としてしまいがちな部分にリスクが潜んでいます。
今回紹介した事例からも、些細な手順の見逃しや設定ミスが重大な問題に発展する可能性があることがわかります。
ヒヤリ・ハット体験を通じて、システムや運用フローを見直し、日々の管理に対する意識を高めることが、未然にリスクを防ぐ鍵となります。
今後もセキュリティ対策を強化し、問題が発生する前に対策を講じることが大切です。
皆さんも、自社のクラウド環境を定期的に振り返り、より堅牢なセキュリティ基盤を築いていきましょう！！！😄