Go to Qiita Advent Calendar 2024 Top
LoginSignup
7
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ヒヤリとした！クラウドセキュリティ体験談をシェアしよう by NetskopeAdvent Calendar 2024

Day 25
@_akira19(Akira)

[クラウドセキュリティ]ヒヤリハットとその対策10選

Posted at

はじめに

自分が経験したとか周りで観測したヒヤリハットとやっといて良かった、やっておけばもっと楽だったことを挙げていきます。
なお、自分がAWSをメインに使ってるので対応はAWS前提でのお話ですが、一般的な対応や多分他のクラウドでも同じことができるものあるので同様の対策してもらえると良いかと思います。

1. 意外に高い

そんなに大したことしてないのに意外にAWSの料金高いなって思ったことありませんか？
以下の項目調べてみてください。

  • IPv4アドレス
    以前は使ってないのに確保しているEIPだけ料金かかっていましたが、今はPublicなIPv4アドレス全てにお金がかかります。EC2とか分かりやすいですが、ALBとかもPublicにおいてたらIPアドレス割り当てられるので、実はAZごとにお金かかってます。
    じゃあ新しいのはIPv6だけで作ってみるかって思ったら、意外にIPv6対応してないISPも多いと知り断念しました。社内で使うサービスとかはIPv6だけで作ってみても良いかもですね。

    パブリック IPv4 アドレスの利用に対する新しい料金体系を発表
    　

  • NAT Gateway
    これは地味にお金かかりますね。サーバーをPrivateに置いてNAT Gatewayで外部とアクセスするっていう構成はベストプラクティスかもしれませんが、dev環境とかはPublicに置いてNAT Gateway使わないっていう選択肢もありです。
    　

  • CloudWatch Logs
    こちら作成するとデフォルトでは保存期間が無限で、リソースがある間はずっと保存しているログの量に比例して料金がかかってしまいます。
    dev環境などの特に残す必要ないものは、3日とか1週間に設定し、本番環境のログはS3に保存するなどして安く運用しましょう。

    CloudWatch LogsをS3にエクスポートしてみた（EventBridge編）
    　

  • AuroraDB
    　通常のRDSは基本的にはインスタンスサイズで金額が決まりますが、AuroraDBはデフォルトの設定だとI/Oにも課金されます。そのため、I/Oが多いようなワークロードの場合はAurora I/O最適化を選択した方がコスト優位です。

image.png

  • VPC Endpoint
    Session Managerを使ってEC2にアクセスする際に必要だったりするのですが、意外にこれも高いです。特にSession Managerを使ったSSHするためにVPC Endpointを3つ作る必要があり、3倍値段がかかります。

    調べたところ、最近2つに減ったらしいので3つで運用している人は2つにしてみるのも良いかもしれません。また、そもそもEC2がPublicにあれば、VPC Endpoint作る必要もないのでその確認もしてみると良いでしょう。

    SSM セッションマネージャーに必要なVPCエンドポイントが2つになっていた
    　

  • スナップショット
    EBSやRDSのスナップショットは意外にお金かかりますので、いらないやつはどんどん消しましょう。
    　

  • Amplify
    SSRでアプリを構成していると、コンピューティングに料金がかかってしまいます。Amplifyはオールインワンでやってくれてあまり意識してないかもですが、注意が必要です。意外に高くかかってしまうので可能であればSSGでアプリケーションを作成した方が良いかと思います。

2. ディスクが満杯でSSHできない

これはサーバー運用あるあるの一つです。EC2やオンプレサーバーにSSH接続しようとすると、気づいたらディスクが満杯でログインすらできない状態になることがあります。

対策

  • 再起動
    EC2を再起動すると、OSやディストリビューションによって異なりますが、/tmpディレクトリが削除される設定になっている場合があります。最近は再起動しても残すようにしてるディストリビューションもあるそうなのですが、とりあえず一旦試してみるのはありかと思います。
    　　

  • ディスク残量をモニタリングする
    ディスクの残量が少なくなったら、slack等に通知するようにします。そうしたら、気づいたときにディスクの容量を増やせます。ディスクのサイズを増やす方法は以下です。
    EC2インスタンスのEBSボリュームサイズを変更する方法
    　

  • ログをローテーションする
    ディスクを圧迫する原因の1つはログファイルが溜まりすぎていることです。
    ログローテーションである一定量しか残さないようにするか、そもそもCloudWatch Logsのように外部にログを送ってローカルには残さないようにする運用にした方が良いですね。
    Amazon CloudWatch Logs とは
    　

  • 他の方法
    こちらにEBSを別のEC2にマウントするなど、他の方法が紹介されてます。
    ディスクフルになって接続できなくなった場合の対処方法

3. アクセスキーが漏れて勝手にリソース作られてる

アクセスキーが漏洩し、悪意のある第三者がAWSリソースを勝手に作成して請求額が爆発する事態はまあよく聞く話です。そもそもアクセスキーは発行しない運用がベストではあるのですが、どうしても発行しないといけない場合には、権限は絞りましょう。最小権限については今回は割愛します。

対策

  • git-secrets
    publicなリポジトリにキーをpushするっていうのが一番ありがちなケースです。
    また、privateリポジトリでもどこかのタイミングでpublicになって、過去のcommitから取得されるっていうことも十分あり得ます。

    secretをpushしているリポジトリがないかクロールしてるbotもあるそうで、pushしたらすぐにsecret抜き取られるそうです。
    そこでそもそもpushできないようにセットしておきましょう。
    git-secretsでパスワードのプッシュを防ぐ方法
    　

  • 請求アラートの設定
    請求額が急上昇した際にアラートを受け取れるようにAWS Budgetsを設定しておきましょう。
    AWS Budgets
    　

  • CloudTrailで追跡
    CloudTrailを有効化しておくことで、リソース作成のログを確認できます。異常な動作を検知するのに役立ちます。
    AWS CloudTrail とは?

当該アクセスキーが分かったら、まずはそのアクセスキーを無効化しましょう。

4. 引き継いだは良いもののドキュメント少なめ

前任者がすでに退職とかしていて何も聞けないみたいな状態ですね。
クラウドに限らずですが、EC2などのVMやオンプレサーバーに直接入って操作する場合、まずやるべきことは

historyで読める量を最大限にしておく

これですね。
とりあえず何かあったときに作業ログがあるとちょっと安心です。

Bashシェルのhistoryの保存件数を増やす

HISTCONTROLとかhistory関連の動作をいじる環境変数が色々存在するのでこの辺も設定しておくと良いかもしれません。

コマンド履歴の達人を目指してみる

5. セキュリティグループで公開したくないポートを誰でもアクセスできるようにしてしまう

セキュリティグループの設定ミスで、不必要なポートがインターネットに公開されてしまうことがあります。

対策

  • セキュリティグループのデフォルトルールを見直す
    不要なオープンルールを削除し、IPアドレス範囲を最小限に絞ります。
    　
  • AWS Configで監視
    AWS Configを設定して、セキュリティグループのルールに異常がないか監視します。
    AWSセキュリティグループの自動修復とカスタマイズ対応

6. Lambdaに環境変数でsecretな情報書いていて、コンソールでは丸見え

Lambdaの環境変数にAPIキーやデータベースパスワードを記載していると、意図せずに他のユーザーに見られる可能性があります。

対策

7. 勝手に自分が持ってるドメインでメール送られる

自分の所有するドメインが悪用されてスパムメールが送信される事例は珍しくありません。このような事態が起きると、ドメインの信頼性が損なわれる可能性があります。

対策

  • SPFレコードの設定
    DNSにSPFレコードを追加し、自分が許可したメールサーバー以外からメールが送信されないようにします。

  • DKIMの有効化
    DKIMを使用してメールが改ざんされていないことを受信者側で確認できるようにします。AWS SESを使う場合は簡単に設定できます。

  • DMARCの設定
    SPFやDKIMを補完する形でDMARCを設定し、メールの検証ポリシーを強化します。

    Amazon SESとAmazon Route 53によるDKIM, SPF, DMARCの設定 － DMARCパラメータの概要と設定例 －

8. 間違ってリソース消してしまう

誤って重要なリソースを削除してしまうことは、クラウド運用における大きなリスクです。

対策

  • 削除防止の有効化
    AWSリソース（特にS3バケットやIAMポリシー）には削除防止機能を有効化することができます。またEC2は終了保護機能があり、間違って消せないようになっています。
    S3 Object Lock を使用したオブジェクトのロック

    　
  • CloudFormationやTerraformの活用
    手動操作ではなく、Infrastructure as Codeを採用し、リソースの管理をコード化します。間違って削除してもすぐに復元可能です。
    　
  • バックアップの自動化
    定期的にバックアップを取得し、誤削除に備えましょう。RDSやEBSにはスナップショット機能があります。

9. IAMの権限が強すぎて担当外のリソースをいじられる

IAMの権限設定が不適切だと、意図しないリソース操作が可能になり、システム全体の安全性が脅かされることがあります。

対策

10. 負荷テスト行ったら悪意のある使い方と判定されアカウントロックされる

負荷テストを実施した際、AWSがその挙動を悪意ある行為と判断してアカウントをロックすることがあります。
ただかなりの負荷をかけない限りは問題なさそうです。

全体として 1 分を越えて継続する、1 Gbps (10 億ビット/秒) または 1 Gpps (10 億パケット/秒) を超えるもの。

ネットワーク負荷テスト

対策

  • AWSに事前通知する
    もし上記の制限を超えそうな負荷テストを行う前にAWSサポートに連絡し、テストの目的と期間を伝えておきます。
    AWSサポートへの問い合わせ
7
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?