AWSセキュリティグループの削除前に確認すること

AWSのセキュリティグループ(Security Group、以下SG)を整理するときに、どのような確認が必要なのかを学習用・検証用の環境を想定して整理する。 はじめに SGは、EC2などのAWSリソースに対する通信を制御する仮想ファイアウォールです。SGにはインバウンドルールとアウトバウンドルールがあり、どの送信元からどのポートへの通信を許可するかを定義します。 SGを整理していると、広い範囲からのアクセスを許可するルールや、用途が分からないSGを見つけることがあります。しかし、ルールが広いからといって、すぐに削除してよいとは限りません。 削除前には、次の2つを分けて考える必要があります。 その通信ルールは業務上必要なのか そのSGは現在どのリソースに関連付けられているのか 0.0.0.0/0とは 0.0.0.0/0は、すべてのIPv4アドレスを表すCIDRです。SGのインバウンドルールでこの値を指定すると、指定したポートへの通信を、送信元IPアドレスによらず許可することになります。 たとえば、次のルールは世界中のIPv4アドレスからSSH接続を許可します。 プロトコル ポート 送信元 意味 TCP 22 0.0.0.0/0 すべてのIPv4アドレスからSSHを許可 このような設定では、インターネット上のスキャンや攻撃の対象になる可能性が高くなります。特にSSH(22番)やRDP(3389番)、データベースのポートなどを全世界に公開するのは危険です。 一方で、公開WebサイトのHTTP(80番)やHTTPS(443番)では、利用者の送信元IPを事前に限定できないため、0.0.0.0/0を使うことがあります。この場合も、Webサーバーやロードバランサーなど、公開が意図されたリソースにだけ関連付けることが重要です。 また、今回問題にしたいのは主にインバウンドルールです。アウトバウンドの0.0.0.0/0は、リソースからインターネット上のサービスへ接続するために使われることがあり、インバウンドと同じ意味で単純に判断できません。 未使用のSGを整理する理由 未使用のSGを残しておくと、今すぐ通信が発生するわけではありません。しかし、将来そのSGを誤ってEC2やENIなどに関連付けたとき、広い範囲からのアクセスを許可する設定が意図せず有効になる可能性があります。 また、不要なSGが多いと、名前やルールを見ただけでは「現在使われている設定なのか」「過去の作業の残りなのか」を判断しにくくなります。これは、設定ミスや変更時の事故につながります。 そのため、未使用であることを確認できたSGは、削除または廃止候補として整理する価値があります。 本当に使われていないかを確認する SGを削除する前に、少なくとも次の観点で確認します。 EC2インスタンスやENIに関連付けられていないか 他のSGのルールから参照されていないか ロードバランサー、RDS、ECSなどのAWSサービスで使われていないか Auto Scaling、起動テンプレート、CloudFormationなどで指定されていないか TerraformやAWS CDKなどのIaCで管理されていないか 今後必要になる予定のSGではないか SGのルールを確認する まず、対象SGの所属VPCやルールを確認します。以下は実際の環境で実行する場合の形式例です。値は自分の確認対象に置き換えます。 1 2 3 4 aws ec2 describe-security-groups \ --group-ids sg-xxxxxxxxxxxxxxxxx \ --profile <profile> \ --region <region> IpPermissionsがインバウンドルール、IpPermissionsEgressがアウトバウンドルールです。0.0.0.0/0だけでなく、::/0というIPv6の全アドレスを表すルールも確認します。 ENIへの関連付けを確認する SGはEC2インスタンスだけでなく、Elastic Network Interface(ENI)に関連付けられます。ロードバランサーやRDS、ECSなど、AWSサービスが管理するENIに関連付けられていることもあります。 ...

2026年9月12日 · 2 分 · 215 文字 · kushun

AWSでMFAを強制する方法とIAM Identity Centerの使い分け

外部ファイルなしでMarkdownに画像を埋め込む方法のメモ。Data URIスキームを使う。

2026年9月12日 · 1 分 · 159 文字 · kushun

SMTPとMIME、メールが日本語や画像を運べる仕組みを整理する

MIMEについて学んだことのアウトプット はじめに 最近SMTPプロトコルとMIMEについて勉強したので、理解の整理を兼ねてアウトプットします。「メールって普通に日本語も画像も送れるけど、裏側では何が起きているんだろう?」という疑問からスタートしました。 SMTPはASCII文字しか扱えない SMTP(Simple Mail Transfer Protocol)はメールを送信するためのプロトコルですが、もともとはASCII文字(7bit)しか安全に運べないという制約を持っていました。 つまり素のSMTPでは、 日本語などの非ASCII文字 画像やPDFなどのバイナリデータ をそのまま送ることができません。これではメールとして不便すぎるので、この制約を解消するために生まれたのがMIMEです。 MIMEはメールのフォーマットを拡張する仕組み MIME(Multipurpose Internet Mail Extensions)は、SMTPそのものを拡張するプロトコルというよりは、メールメッセージのフォーマットを拡張する規格です。SMTPは「メールを転送する仕組み」、メール本文の書式は別の規格(RFC 5322)で定義されており、MIMEはこの書式を拡張して、テキスト以外のデータ種別やエンコーディング方式を表現できるようにしています。 MIMEは主に次のようなヘッダーで構成されます。 Content-Type:データの種類を示す(text/plain、image/png、application/pdf、複数の要素を含む場合はmultipart/mixedなど) Content-Transfer-Encoding:データをASCII文字だけの形にどう変換したかを示す(Base64、Quoted-Printable、7bitなど) charset:文字コードの指定(UTF-8、ISO-2022-JPなど) 変換の流れ:文字コード変換 → 転送用エンコード 日本語のテキストを送る場合、実は2段階の変換が行われています。 文字コード変換(charset):日本語の文字を、指定した文字コードのバイト列に変換する 転送用エンコード(Content-Transfer-Encoding):そのバイト列を、SMTPで安全に運べるASCII文字列の形に変換する 例えばcharset=UTF-8と指定した場合は「日本語→UTF-8のバイト列」に変換され、そのバイト列はASCIIの範囲を超える(8bit全部を使う)ため、さらにBase64やQuoted-Printableで包む必要があります。 一方、charset=ISO-2022-JPの場合は少し特殊です。ISO-2022-JPは、エスケープシーケンスという特殊な合図の文字列を使うことで、日本語も含めてすべて7bit(ASCIIの範囲)のバイト列だけで表現できるように設計された文字コードです。つまりISO-2022-JPに変換した時点で、すでにSMTPの制約をクリアしています。そのため、Content-Transfer-Encodingとして追加のエンコードをせず7bit(そのまま送れる、という意味の指定)が使われることが伝統的に多いです。 まとめると: charset 文字→バイト列の変換 追加の転送用エンコードは必要? UTF-8 日本語→UTF-8バイト列 必要(Base64やQuoted-Printableが多い) ISO-2022-JP 日本語→ISO-2022-JPバイト列(エスケープシーケンス使用) 基本不要(7bit指定で足りる) 画像やPDFの場合 画像やPDFなどのバイナリデータは、そのままだとASCII文字ではないので、Base64エンコードによってASCII文字列に変換してから本文に埋め込みます。添付ファイルが複数ある場合は、multipart/mixedという指定で「本文」と「添付」を区切り(boundaryという文字列で境界を示す)、一通のメールにまとめます。 全体の流れ 送信側: メールに日本語・画像・PDFなどが含まれる MIMEでそれぞれのデータ種別(Content-Type)を記述 charsetで文字コードを指定し、必要なら転送用エンコード(Base64など)を適用 SMTPで運べる形(ASCII文字列)になったメールを送信 受信側: SMTPでメールを受信 MIMEヘッダー(Content-Type、Content-Transfer-Encoding、charsetなど)を確認 その情報をもとに、エンコードされたデータを元の日本語・画像・PDFなどに復元 正しいデータとして閲覧できる おまけ:MIMEはメール以外にも影響を与えている Content-Typeヘッダーはメールだけでなく、HTTP通信でも使われています。Webサーバーがブラウザに「これはHTMLです」「これは画像です」と伝えるあの仕組みも、もとをたどればMIMEで定義された考え方です。メールのために生まれた規格が、Webの基盤の一部にもなっているというのは面白いポイントだと思いました。 まとめ SMTPはASCII文字しか運べないプロトコル MIMEはメールのフォーマットを拡張し、非ASCIIデータをASCIIの形に変換して運べるようにする規格 変換は「文字コード変換」と「転送用エンコード」の2段階(文字コードによっては後者が省略されることもある) MIMEの考え方はHTTPのContent-Typeなど、Web全体にも影響を与えている

2026年9月6日 · 1 分 · 60 文字 · kushun

MCP超入門 ── AIに「道具」を持たせる仕組みを理解する

MCPとは何か、なぜ必要か、どう動くかを、社内でAI活用を始めたい人向けにわかりやすく整理した。

2026年8月21日 · 3 分 · 473 文字 · kushun

Next.jsのSSR・SSG・Hydrationを整理して理解した

Next.jsプロジェクトへSDKを組み込む際にdynamic importとssr: falseが必要になったことをきっかけに、SSR・SSG・Hydrationの仕組みを整理した。

2026年7月12日 · 1 分 · 183 文字 · kushun

Markdownに画像をbase64で直接埋め込む

外部ファイルなしでMarkdownに画像を埋め込む方法のメモ。Data URIスキームを使う。

2026年7月2日 · 1 分 · 192 文字 · kushun

初OSSコントリビュート振り返り〜WholePizza ParrotのPRで学んだこと

cult of the party parrot に自作GIFを投稿し、レビュアーとやり取りしながらPRをマージするまでの体験記。GIF透過処理やgifsicle最適化のハマりどころと、OSSコミュニケーションで学んだことをまとめます。

2026年3月19日 · 2 分 · 269 文字 · kushun

npm create vite@latest 実行で出たエラーを解決した

npm create vite@latest でReactプロジェクトを作成したところVSCode上でTypeScriptのエラーが発生。原因はVSCode内蔵のTypeScriptバージョンの古さにありました。

2026年3月11日 · 1 分 · 99 文字 · kushun

S3署名付きURL入門 - 期限付きで安全にファイルを共有する方法

AWS S3の署名付きURL(Presigned URL)を使って、期限付きで安全にファイルを共有する方法を初心者向けに解説します。

2026年2月8日 · 2 分 · 359 文字 · kushun

TypeScript Partial型入門 - オブジェクトのプロパティをすべてオプショナルにする

TypeScriptのPartial型について初心者向けに解説します。使い方、実践例、仕組みまでわかりやすく説明します。

2026年2月5日 · 3 分 · 601 文字 · kushun