公開更新 23 人が閲覧（直近 30 日） セキュリティ

RSA暗号とは？仕組みと鍵長・パディングの選び方をOpenSSLの実装で解説

RSA暗号とは？仕組みと鍵長・パディングの選び方をOpenSSLの実装で解説

RSA暗号は、巨大な合成数の素因数分解が現実的な時間で解けないことを安全性の根拠にした公開鍵暗号方式です。1977年に発表され、TLSの証明書、SSHの公開鍵認証、電子署名、ソフトウェアの署名検証といった土台で今も動いています。

この記事では、鍵生成から暗号化・復号の計算手順を追い、OpenSSLとPythonで鍵を作って暗号化・署名を動かします。後半ではRSA-OAEPとRSA-PSSを選ぶ根拠、2030年・2035年の期限から逆算した鍵長の移行判断、鍵を棚卸しして詰まった箇所を扱います。

まとめ：RSA暗号で先に決める鍵長・パディング・移行期限

結論を先に置きます。RSAは「使うか使わないか」ではなく「どのパラメータで、いつまで使うか」を決める対象になりました。

  • 新規実装の鍵長は3072ビットから考える：2048ビットは112ビット相当の強度で、後述する期限の対象に入ります。OpenSSLの既定値は2048ビットなので、指定を省くと期限つきの鍵ができます。
  • パディングはRSA-OAEPとRSA-PSSを選ぶ：RFC 8017は新規実装にこの2つを求めています。PKCS#1 v1.5系は互換のために残っている選択肢です。
  • 期限は2030年と2035年の2段：NIST IR 8547の初期公開草案は、112ビット強度のRSAを2030年以降は非推奨、2035年以降は禁止と整理しました。128ビット強度以上でも2035年で線が引かれています。
  • 平文そのものをRSAで暗号化しない：RSAで運ぶのは共通鍵で、データ本体はAESで暗号化します。この分担がハイブリッド暗号方式です。
  • 同じ強度なら楕円曲線暗号のほうが軽い：新規で署名だけが要件なら、ECDSAとRSAの違いから鍵の種類ごと選び直せます。

RSA暗号の仕組み｜鍵生成から暗号化・復号までの計算手順を追う

まず計算の中身を押さえます。ここを飛ばすと、鍵長の議論もパディングの必要性も理解できないまま設定値を写すことになります。

公開鍵と秘密鍵を作る手順｜素数p・qと公開指数65537の役割

鍵生成は4つの計算で終わります。まず大きな素数を2つ選び（pとq）、その積をnとします。このnが公開鍵の一部となる法（モジュラス）で、鍵長3072ビットという表現はnの大きさを指したものです。続いて(p-1)と(q-1)の積からオイラー関数の値を求め、これと互いに素な数eを公開指数として選び、最後にeの逆元dを求めて秘密指数とします。

公開鍵は(n, e)の組、秘密鍵は(n, d)の組です。eには65537が広く使われており、python cryptographyの公式ドキュメントも、generate_private_keyの解説で「特別な理由がない限り常に65537を使うべき」と明記しています。この値が選ばれる理由は2つあり、二進表記が1が2個だけの形でべき乗計算が速く終わること、3のような小さすぎる指数で知られる攻撃を避けられることです。

pとqは秘密鍵の中に保持されており、これが漏れればnの素因数分解が済んだのと同じ状態になります。秘密鍵ファイルの保護がRSAの安全性そのものになるという構図です。共通鍵暗号との役割分担は公開鍵暗号方式と共通鍵暗号方式の違いで扱っています。

べき乗と剰余による暗号化の計算とRSAが素因数分解に頼る理由

暗号化は、平文を数値mとして扱い、mのe乗をnで割った余りを求めるだけです。復号は、その結果のd乗をnで割った余りを取ります。この2つの操作が互いを打ち消す関係にあることが、RSAの数学的な核です。署名の場合は向きが逆になり、秘密指数dで計算した値を公開指数eで戻して一致を確かめます。

攻撃者は公開鍵(n, e)を知っています。dを求めるにはオイラー関数の値が必要で、そのためにはnをpとqへ分解しなければなりません。桁数の大きな合成数の素因数分解に効率的な方法が見つかっていないことが、安全性の根拠です。逆に言えば、素因数分解が速くなる計算手段が現れた瞬間にこの根拠は崩れます。量子コンピュータで動くショアのアルゴリズムが問題視されるのは、この点です。

仕様の全文はRFC 8017（PKCS #1 v2.2）にあります。2016年11月発行でRFC 3447を廃止しており、鍵の表現形式、暗号化スキーム、署名スキームがまとめて定義された文書です。暗号化そのものの位置づけは暗号化とはで整理しています。

OpenSSLでRSA鍵を生成し暗号化と署名を実際に動かす手順

ここから手を動かします。OpenSSLが入っていれば追加のインストールは不要で、鍵生成から署名検証まで数分で通せます。

openssl genpkeyでの鍵生成と鍵長の既定値2048の確認手順

鍵生成にはgenpkeyを使います。旧来のgenrsaも動きますが、鍵の種類ごとにコマンドが分かれないgenpkeyのほうが後の運用で扱いやすい形です。ここで注意すべきなのは既定値です。openssl-genpkeyのmanページには「The number of bits in the generated key. If not specified 2048 is used.」と書かれています。鍵長を指定しないと2048ビットの鍵ができます。

# 3072ビットのRSA秘密鍵を生成（公開指数は既定の65537）
openssl genpkey -algorithm RSA -out private.pem \
  -pkeyopt rsa_keygen_bits:3072

# 秘密鍵から公開鍵を取り出す
openssl pkey -in private.pem -pubout -out public.pem

# 鍵長と公開指数を確認する
openssl pkey -in private.pem -noout -text | head -4

最後の確認コマンドで「Private-Key: (3072 bit, 2 primes)」と表示されれば意図した鍵長です。公開指数は「publicExponent: 65537 (0x10001)」の行で読めます。公開指数を変えるオプション（rsa_keygen_pubexp）も用意されていますが、変更する理由が説明できない限り触らないでください。

pkeyutlでのOAEP暗号化とdgstでのPSS署名・検証の実行例

暗号化にはpkeyutlを使い、パディング方式を明示します。オプションの一覧はopenssl-pkeyutlのmanページにあり、rsa_padding_modeを指定しない場合の既定はPKCS#1 v1.5です。指定を省くと意図せず互換モードで動きます。次の例では、実務の形に合わせてAES用の鍵素材32バイトをRSAで包んでいます。

# 共通鍵の材料となる32バイトを作る
openssl rand -out session.key 32

# 公開鍵でOAEPパディングを明示して暗号化
openssl pkeyutl -encrypt -inkey public.pem -pubin \
  -in session.key -out session.key.enc \
  -pkeyopt rsa_padding_mode:oaep \
  -pkeyopt rsa_oaep_md:sha256 \
  -pkeyopt rsa_mgf1_md:sha256

# 秘密鍵で復号し、元のバイト列と一致するか確かめる
openssl pkeyutl -decrypt -inkey private.pem \
  -in session.key.enc -out session.key.dec \
  -pkeyopt rsa_padding_mode:oaep \
  -pkeyopt rsa_oaep_md:sha256 \
  -pkeyopt rsa_mgf1_md:sha256

cmp session.key session.key.dec

署名はdgstで行います。ソルト長はdigestでハッシュ長に合わせるのが扱いやすく、検証側と値が揃わないと失敗するため、送受で仕様を合わせてください。

# PSS方式で署名（ソルト長をダイジェスト長に合わせる）
openssl dgst -sha256 -sign private.pem \
  -sigopt rsa_padding_mode:pss \
  -sigopt rsa_pss_saltlen:digest \
  -out contract.sig contract.pdf

# 公開鍵で検証（Verified OK が返れば成功）
openssl dgst -sha256 -verify public.pem \
  -sigopt rsa_padding_mode:pss \
  -sigopt rsa_pss_saltlen:digest \
  -signature contract.sig contract.pdf

ここまで通れば、RSAの3つの用途（鍵の受け渡し・署名・検証）を手元で再現できた状態です。同じ鍵の考え方で動くSSH接続の公開鍵認証も運用側の参考になります。

PythonのcryptographyでOAEP暗号化とPSS署名を実装する

アプリケーションへ組み込む場合はライブラリを使います。Pythonではcryptographyが標準的な選択肢で、OpenSSLをバックエンドに持ちながらパディングを型で指定させる設計になっています。

generate_private_keyでの鍵生成とkey_sizeの指定値の判断

鍵生成のAPIはrsa.generate_private_keyで、引数は公開指数と鍵長の2つです。公式ドキュメントは鍵長について「1024ビット以下は破られるものと見なされ、2048または4096が妥当な既定値」と記述しています。ここでの判断は後述する期限と合わせて決めることになりますが、新規なら3072ビット以上を入れてください。

from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding, rsa

# 鍵生成：公開指数は65537、鍵長は3072ビット
private_key = rsa.generate_private_key(public_exponent=65537, key_size=3072)
public_key = private_key.public_key()

print(private_key.key_size)

3072ビットの鍵生成は素数の探索を伴い、体感できる時間がかかります。リクエストごとに鍵を作る設計にはせず、事前に生成して安全な保管領域へ置き、アプリケーションは読み込むだけにしてください。

OAEPでの暗号化とPSSでのsalt_length指定を含む署名の実装

暗号化ではOAEPのハッシュとMGF1のハッシュを揃えます。片方だけSHA-256にして他方をSHA-1のままにすると、復号側と噛み合わずに失敗します。公式ドキュメントのコード例と同じ形を維持するのが安全です。

# OAEPで暗号化（ハッシュとMGF1のハッシュを揃える）
ciphertext = public_key.encrypt(
    b"session-key-material",
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None,
    ),
)

plaintext = private_key.decrypt(
    ciphertext,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None,
    ),
)
assert plaintext == b"session-key-material"

署名側ではsalt_lengthの指定が要ります。公式ドキュメントはPSS.DIGEST_LENGTHまたはPSS.MAX_LENGTHを推奨しています。検証が通らないときの原因はここに集まるため、署名と検証で同じ値を使っているかを最初に確認してください。

from cryptography.exceptions import InvalidSignature

message = b"invoice-2026-09"

signature = private_key.sign(
    message,
    padding.PSS(
        mgf=padding.MGF1(hashes.SHA256()),
        salt_length=padding.PSS.DIGEST_LENGTH,
    ),
    hashes.SHA256(),
)

try:
    public_key.verify(
        signature,
        message,
        padding.PSS(
            mgf=padding.MGF1(hashes.SHA256()),
            salt_length=padding.PSS.DIGEST_LENGTH,
        ),
        hashes.SHA256(),
    )
    print("署名は正当")
except InvalidSignature:
    print("署名が一致しない")

Goのcrypto/rsaで同じ処理を書くときのAPIの対応関係

Goでは標準ライブラリだけで完結します。crypto/rsaのパッケージドキュメントを見ると、OAEPはEncryptOAEPとDecryptOAEP、PSSはSignPSSとVerifyPSSで、Python側と関数名の対応が取れた構成です。違いは乱数源を引数で渡す点だけです。

package main

import (
    "crypto/rand"
    "crypto/rsa"
    "crypto/sha256"
    "fmt"
)

func main() {
    priv, err := rsa.GenerateKey(rand.Reader, 3072)
    if err != nil {
        panic(err)
    }
    msg := []byte("session-key-material")

    enc, err := rsa.EncryptOAEP(sha256.New(), rand.Reader, &priv.PublicKey, msg, nil)
    if err != nil {
        panic(err)
    }
    dec, err := rsa.DecryptOAEP(sha256.New(), rand.Reader, priv, enc, nil)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(dec))
}

第5引数のlabelはOAEPのラベルで、送信側と受信側で同じ値にする必要があります。使い道がなければnilで揃えてください。片側だけに値を入れると復号が失敗します。

パディング選択でRSA-OAEPとRSA-PSSを使う理由と旧方式の扱い

RSAの事故はアルゴリズム本体ではなくパディングで起きてきました。ここは設定値の丸暗記ではなく、どちらが推奨側かを一次情報で確かめて選ぶ場面です。

RSAES-PKCS1-v1_5が運用監視暗号リストに移った意味と影響

RFC 8017の§7には「RSAES-OAEP is REQUIRED to be supported for new applications; RSAES-PKCS1-v1_5 is included only for compatibility with existing applications」と書かれています。§8の署名側も「RSASSA-PSS is REQUIRED in new applications」です。仕様書の側で新旧の扱いが分かれている状態です。

日本の調達では線がさらに明確です。CRYPTREC暗号リスト（CRYPTREC LS-0001-2022R2・最終更新2026年3月30日）の電子政府推奨暗号リストには、署名としてRSA-PSSとRSASSA-PKCS1-v1_5、守秘としてRSA-OAEPが載っています。一方で守秘のRSAES-PKCS1-v1_5は運用監視暗号リスト側に置かれ、注13で「TLS 1.0, 1.1, 1.2で利用実績があることから当面の利用を認める」と条件付きの扱いになりました。

用途 推奨側の方式 互換のための方式
暗号化（守秘） RSA-OAEP RSAES-PKCS1-v1_5
署名 RSA-PSS RSASSA-PKCS1-v1_5
OpenSSLの既定 指定が必要 PKCS#1 v1.5

実装上の含意は単純です。守秘の用途でPKCS#1 v1.5を選ぶには、相手先の実装が対応していないという説明が要ります。署名側は推奨リストに両方が残っているため、既存システムとの相互運用でv1.5署名を続ける判断は取れます。

平文を直接RSAで暗号化しない設計｜ハイブリッド暗号への分担

RSAで暗号化できるデータ量は鍵長で決まります。3072ビットの鍵にSHA-256のOAEPを使う場合、扱える平文は数百バイト程度です。ファイルや長い本文をそのままRSAへ渡す設計は、量の面でも速度の面でも成立しません。

実際の系では、データ本体をAESなどの共通鍵で暗号化し、その共通鍵だけをRSAで包んで相手へ渡します。TLSもこの構造を踏襲してきました。組み合わせ方の全体像はハイブリッド暗号方式とはで扱っており、通信での実装はTLSとはのバージョン選定とあわせて見ると設計しやすくなります。

鍵長は3072ビットへ｜2030年と2035年の期限から逆算する移行計画

鍵長の話は「長いほど安全」で終わりません。いつまで使えるかという期限が公的文書で示されたため、逆算が要る話に変わりました。

112ビット強度の期限｜2030年非推奨・2035年禁止の原文の記述

NIST IR 8547は2024年11月12日に公開された初期公開草案で、2026年9月時点で最終版は出ていません。草案という前提は付きますが、Table 3の記載は具体的です。RSAとECDSAについて、112ビット相当の強度は「Deprecated after 2030」「Disallowed after 2035」、128ビット相当以上でも「Disallowed after 2035」と整理されています。

もう一つ押さえておきたいのが、この文書が既存計画を変更している点です。本文には、SP 800-57 Part 1では112ビット強度の公開鍵方式を2031年1月1日にdisallowとする見通しだったが、量子耐性への移行が同じ時期に重なるため、非推奨（deprecate）へ変更する意向だと書かれています。禁止が緩んだのではなく、移行期間として2030年から2035年の5年が置かれた形です。

RSA鍵長 相当する強度 草案が示す扱い
1024ビット 80ビット未満 既に対象外
2048ビット 112ビット 2030年以降は非推奨
3072ビット 128ビット 2035年以降は禁止
4096ビット以上 128ビット超 2035年以降は禁止

表の最後の2行が移行計画の前提です。鍵長を伸ばしても2035年の線は動きません。鍵長の引き上げは2030年の非推奨を回避する手当てであって、量子耐性の獲得ではないという切り分けが要ります。

鍵長を3072ビットへ上げる際の性能と証明書の互換性の見積り

2048ビットから3072ビットへ移すと、鍵生成と秘密鍵側の演算（復号・署名）が目に見えて遅くなります。公開鍵側の演算（暗号化・検証）は指数が65537と小さいため影響が限定的で、検証だけを行う側の負担は軽いままです。署名を大量に生成するサーバーでは、負荷の変化を測ってから移してください。

互換性の面では証明書の再発行が伴い、組み込み機器や古いミドルウェア、決済系の相手先が対応鍵長を制限している場合もあるため、自社側の切り替えだけでは終わりません。期限の近い証明書から鍵長を上げ、相手先の制約が判明したものを個別に例外管理する順序が現実的です。

受託開発でRSA鍵と証明書を棚卸しして詰まった箇所と対処の設定

ここからは手順の紹介では出てこない部分です。期限が決まった以上、最初の作業は新規実装ではなく現状把握になります。そして現状把握が想像より難しいという壁に当たります。

鍵長1024ビットの残存と失効期限が不明な鍵を洗い出す調べ方

長く動いている案件では、鍵がリポジトリ、サーバー、CIのシークレット、担当者の手元と分散しています。まずは機械的に鍵長を並べるところから始めるのが早道です。次のスクリプトは、手元のPEMファイルを走査して鍵長順に並べます。

#!/usr/bin/env bash
# 手元のPEM秘密鍵と証明書の鍵長を一覧にする（1024ビット残存の洗い出し）
set -u

for f in $(find . -name "*.pem" -o -name "*.key"); do
  bits=$(openssl pkey -in "$f" -noout -text 2>/dev/null \
    | grep -o "Private-Key: ([0-9]* bit" | grep -o "[0-9]*")
  echo "${bits:-unknown} $f"
done | sort -n

# 証明書側は公開鍵の鍵長を見る
for c in $(find . -name "*.crt"); do
  bits=$(openssl x509 -in "$c" -noout -text \
    | grep -o "Public-Key: ([0-9]* bit" | grep -o "[0-9]*")
  echo "${bits:-unknown} $c"
done | sort -n

出てくるのは、たいてい2048ビットと1024ビットの混在です。難しいのは、1024ビットの鍵が「使われていない」のか「どこかで使われている」のかが分からない状態で、鍵ファイルには用途が書かれていません。指紋を取ってサーバー側の設定と突き合わせる作業が要ります。

# 秘密鍵と証明書の対応を公開鍵のハッシュで突き合わせる
openssl pkey -in private.pem -pubout -outform DER \
  | openssl dgst -sha256

openssl x509 -in server.crt -noout -pubkey \
  | openssl pkey -pubin -pubout -outform DER \
  | openssl dgst -sha256

ハッシュが一致すれば同じ鍵ペアです。棚卸しの成果物として、鍵ごとに「用途・設置場所・鍵長・入れ替え期限」を記録した表を残してください。この4項目が埋まらない鍵は、期限が来ても動かせません。署名鍵の保管先を専有HSMへ移す場合の構築手順と費用はAWS CloudHSMとは？KMSとの違い・東京の料金とクラスター構築手順で扱っています。鍵と証明書の点検を診断の一部として外部に任せる場合は、脆弱性診断・セキュリティ診断のように設定面まで見る診断と組み合わせると、洗い出しから対処までが一本の工程になります。

PKCS#1 v1.5署名の互換要件が残る相手先との折り合いの付け方

もう一つの壁は相手先です。金融系や公共系の連携仕様で、PKCS#1 v1.5署名やRSA-2048が仕様書に明記されている場合があります。この場合、自社の判断だけでPSSへ移せません。

取れる手当ては3つです。第一に、方式を仕様として固定している相手には、更新時期を確認して自社の移行計画へ日付として組み込みます。第二に、自社が発信側で相手が検証側なら、両方の署名を並行して出す期間を設けて切り替える方法があります。第三は、内部通信と外部連携で鍵を分け、外部の制約が内部の鍵長を縛らない構成です。

3つ目が効きます。1つの鍵ペアを社内外で共用していると、最も古い相手先の要件が全体の上限を決めてしまう構図です。鍵を用途別に分ける設計は、棚卸しの段階で決めておくほうが後の入れ替えが軽くなります。

RSAを使い続ける条件と楕円曲線暗号やPQCへ寄せる判断の基準

最後に判断を言い切ります。RSAは撤去すべき技術ではありませんが、新規で無条件に選ぶ技術でもなくなりました。

RSAを維持してよい条件｜相手先の実装と更新周期で決める線引き

次の条件が揃うなら、RSAを続ける判断に無理はありません。相手先の実装がRSAしか受け付けないこと。鍵長を3072ビット以上へ上げられること。そしてシステムの更新周期が2035年より前に来ることです。3つ目が抜けている案件、つまり10年動かす前提の組み込み機器や長期保管の署名では、いま設計しているものが期限に触れます。

署名の検証だけを担う側も維持しやすい立場です。検証は公開指数側の軽い演算で済み、鍵長を上げても負荷が跳ねません。既存の署名を検証し続ける機能は、発行側が切り替えるまで残す形が現実的です。

楕円曲線暗号へ寄せる条件とPQCの移行を待つべき場面の切り分け

新規実装で相手先の制約がないなら、楕円曲線暗号へ寄せる価値があります。同じ強度を短い鍵で得られるため、鍵と署名のサイズが小さく、TLSのハンドシェイクも軽くなります。鍵長と速度の比較はECDSAとRSAの違いで数値を並べているので、選定資料としてはそちらを見てください。

ただし、楕円曲線暗号もIR 8547の草案では2035年で線が引かれる側にあります。したがって「RSAからECDSAへ移せば2035年に対応できる」わけではありません。2035年の線を越える必要がある系では、ML-DSAなど量子耐性のある署名方式への移行が対象になります。いま取るべき順序は、鍵の棚卸しで期限を可視化し、2030年に触れる2048ビット鍵を先に処理し、そのうえで量子耐性方式の標準化と製品対応の進み方を見て切り替え時期を決める形です。棚卸しを飛ばして方式の議論から始めると、対象の数が分からないまま計画が止まります。

よくある質問

RSA暗号の実装と鍵長の判断でよく挙がる質問をまとめました。

RSA暗号の鍵長は2048ビットでは足りないのですか？

いま破られる強度ではありませんが、期限が付いています。NIST IR 8547の初期公開草案では、2048ビット相当（112ビット強度）のRSAは2030年以降が非推奨、2035年以降が禁止と整理されました。稼働中のシステムを今日止める必要はなく、新規に作る鍵は3072ビット以上にし、既存の2048ビット鍵は次の更新タイミングで入れ替える方針が現実的です。証明書の有効期限が2030年より先に伸びる発行では、鍵長を先に上げてください。

RSA-OAEPとRSAES-PKCS1-v1_5はどちらを使うべきですか？

新規実装はRSA-OAEPです。RFC 8017の§7が新規アプリケーションにOAEPの対応を求め、PKCS#1 v1.5は既存との互換のためだけに残されていると明記しています。CRYPTREC暗号リストでも、RSA-OAEPは電子政府推奨暗号リスト、RSAES-PKCS1-v1_5は運用監視暗号リストという扱いに分かれました。OpenSSLのpkeyutlはパディング指定を省くとv1.5で動くため、rsa_padding_mode:oaepを明示してください。

RSAで大きなファイルを暗号化できますか？

できません。扱える平文の長さが鍵長で制限され、3072ビット鍵とSHA-256のOAEPでは数百バイト程度です。実務では、ファイル本体をAESなどの共通鍵暗号で暗号化し、その共通鍵だけをRSAで包んで渡します。この構成をハイブリッド暗号方式と呼びます。ファイルを分割してRSAで繰り返し暗号化する方式は、速度も安全性も見合いません。

公開指数はなぜ65537が使われるのですか？

計算が速く、かつ小さすぎる指数で知られた攻撃を避けられるためです。65537は二進表記で1が2個だけになり、べき乗計算の手数が少なく済みます。python cryptographyの公式ドキュメントも、特別な理由がない限りこの値を使うよう記載しています。3のような小さな値は理論上使えますが、パディングの実装不備と組み合わさったときの危険が知られているため選びません。

量子コンピュータでRSAはいつ解読されますか？

時期を断定できる一次情報はありません。公的文書が扱っているのは解読時期の予想ではなく移行の期限で、NIST IR 8547の草案が置いた2030年の非推奨と2035年の禁止が実務上の判断基準になります。あわせて考えるべきは、いま暗号化した通信を保存して将来復号する形の攻撃です。長期の機密性が要るデータは、期限を待たずに移行を検討する側に入ります。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.23　テックブログ Renta!不正アクセスでサービス停止：再開未定の現状と運営側の停止判断・証拠保全・段階的再開
  2. 2026.10.21　テックブログ ふるさとチョイス不正アクセスで445万件流出：対象確認・パスワード変更と再開時期
  3. 2026.10.24　テックブログ カプコン不正アクセス：CAPCOM ID 1,177万件漏えいと196件の乗っ取りへの対処
  4. 2026.10.24　テックブログ ブラストメール不正アクセス：配信先288件の漏えいと利用企業の報告・通知の手順
  5. 2026.10.17　コラム カスハラ奨励金とは？東京都40万円の第2回要件と11月6日までに間に合う取組

RELATED POSTS 関連記事

一覧へ戻る

目次