diff options
| author | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 21:46:22 -0500 |
|---|---|---|
| committer | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 21:46:22 -0500 |
| commit | a065e04d529da1d847b5062a12c46d916408bf32 (patch) | |
| tree | fe0f8bcec1ff39a3c499a2708222dcf15224ff70 /files/ja/archive/security | |
| parent | 218934fa2ed1c702a6d3923d2aa2cc6b43c48684 (diff) | |
| download | translated-content-a065e04d529da1d847b5062a12c46d916408bf32.tar.gz translated-content-a065e04d529da1d847b5062a12c46d916408bf32.tar.bz2 translated-content-a065e04d529da1d847b5062a12c46d916408bf32.zip | |
update based on https://github.com/mdn/yari/issues/2028
Diffstat (limited to 'files/ja/archive/security')
6 files changed, 0 insertions, 281 deletions
diff --git a/files/ja/archive/security/confidentiality,_integrity,_and_availability/index.html b/files/ja/archive/security/confidentiality,_integrity,_and_availability/index.html deleted file mode 100644 index 923747ca93..0000000000 --- a/files/ja/archive/security/confidentiality,_integrity,_and_availability/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: 機密性・完全性・可用性 -slug: 'Archive/Security/Confidentiality,_Integrity,_and_Availability' -tags: - - セキュリティ - - チュートリアル - - 初心者 -translation_of: 'Archive/Security/Confidentiality,_Integrity,_and_Availability' ---- -<div class="summary" style="margin: 0px 0px 20px; padding: 20px; border: 0px; font-weight: 700; color: rgb(77, 78, 83); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: 21px; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; background: rgb(244, 247, 248);"> -<p style="margin: 0px; padding: 0px; border: 0px;">この記事では情報セキュリティの三大要素である機密性・完全性・可用性について説明します。</p> -</div> - -<p>情報セキュリティの古典的なモデルとして機密性・完全性・可用性の3つの要素を維持することが定義されています。それぞれは異なる面の情報を守ることを目的として定められています。</p> - -<h2 id="Confidentiality" name="Confidentiality">機密性</h2> - -<p><ruby><em>機密性</em><rp> (</rp><rt>Confidentiality</rt><rp>) </rp></ruby>は、権限の無い人物が情報にアクセスすることを防止することを指します。つまりは権限のある人物にのみが機密情報にアクセスできるようにするということです。例えばあなたの銀行の記録なら、あなたはもちろんその記録にアクセスできるべきですし、あなたの手続きを助けてくれる銀行員もアクセスできるべきでしょう。しかしそれ以外の人物はアクセスできないようにすべきです。機密性を損なうということは、権限の無い誰かが故意または過失によって情報にアクセスできてしまうということです。機密性の欠如は一般には"守秘義務違反"として知られていて、基本的には被害者を救済できません。一旦秘密が漏洩してしまえば、再び秘匿することはできないのです。もしあなたの銀行の記録が公開ウェブサイトに投稿されれば、閲覧した全員にあなたの銀行アカウントや残高等を知られてしまいます。そしてその情報は全員の頭の中やコンピュータ等から完全に抹消することはできません。今日のメディアの報道するほぼすべての主なセキュリティインシデントが機密性の欠如に関わるものです。</p> - -<p>要約すると、機密性の侵害は権限の無い誰かが情報にアクセスできてしまうことを意味します。</p> - -<h2 id="Integrity" name="Integrity">完全性</h2> - -<p><ruby><em>完全性</em><rp> (</rp><rt>Integrity</rt><rp>) </rp></ruby>は情報の信憑性を確認できることを指します。つまりは情報が改ざんされておらず、情報の入手元も本物であるということです。例えばあなたがウェブサイトを立ち上げ、商品を販売しているとしましょう。攻撃者が悪意を持って商品の値段を書き換えられるとすれば、攻撃者の好きな値段で商品を買うことができてしまいます。このように書き換えを許可していないあなたの情報(この場合は値段)が改ざんされることが、完全性の欠如にあたります。もう1つの例はあなたがあるウェブサイトに接続しようとしているときに、攻撃者があなたの通信に割り込んで異なるウェブサイトへ誘導するというのも完全性の欠如です。この場合はあなたが誘導されたサイトが本物でない、ということがそれに当たります。</p> - -<h2 id="Availability" name="Availability">可用性</h2> - -<p><ruby><em>可用性</em><rp> (</rp><rt>Availability</rt><rp>) </rp></ruby>は、認証されたユーザが情報にアクセス可能であるということを指します。</p> - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">原典情報</h3> - -<ul> - <li>著者: Karen Scarfone, Wayne Jansen, and Miles Tracy</li> - <li>題名: NIST Special Publication 800-123, Guide to General Server Security</li> - <li>最終更新: July 2008</li> - <li>著作権情報: This document is not subject to copyright.</li> -</ul> -</div> - -<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p> diff --git a/files/ja/archive/security/digital_signatures/index.html b/files/ja/archive/security/digital_signatures/index.html deleted file mode 100644 index ad4b130f1b..0000000000 --- a/files/ja/archive/security/digital_signatures/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: 電子署名 -slug: Archive/Security/Digital_Signatures -tags: - - Security - - Tutorial -translation_of: Archive/Security/Digital_Signatures ---- -<p><span class="seoSummary">暗号化と復号化は、この文書の冒頭で述べた3つのインターネットセキュリティ問題の1つである盗聴の問題に対処するものです。しかし、暗号化と復号化だけでは、別の問題である改ざんには対処できません。</span></p> - -<p>このセクションでは、公開鍵暗号が改ざんの問題にどのように対処するかを説明します。</p> - -<p>改ざん検知および関連する認証技術は、一方向ハッシュ (メッセージダイジェストとも呼ばれる) と呼ばれる数学関数に依存しています。一方向ハッシュは、以下の特徴を持つ固定長の数です。</p> - -<ul> - <li>ハッシュの値は、ハッシュ化されたデータに対して一意です。データに変更があった場合、たとえ1文字を削除したり変更したりしても、結果として異なる値になります</li> - <li>ハッシュ化されたデータの内容は、すべての実用的な目的のために、ハッシュ化されたデータから推論することはできません。それが「一方通行」と呼ばれる理由です</li> -</ul> - -<p>同様に、公開鍵暗号化では、電子署名のためのキーペアが生成されます。キーペアは、<strong>秘密署名鍵</strong>と<strong>公開検証鍵</strong>から構成されます。公開鍵は広く配布されていますが、秘密鍵はその所有者のみが知ることができます。鍵は数学的に関連していますが、公開鍵から秘密鍵を計算することが不可能であるか、あるいは法外なコストがかかるように、パラメータが選択されています。暗号化されたハッシュは、ハッシュアルゴリズムなどの他の情報とともに電子署名として知られています。</p> - -<p>図1は、署名されたデータの整合性を検証するために電子署名を使用する方法を簡略化したものです。</p> - -<p><img alt="Figure 3. Using a Digital Signature to Validate Data Integrity" class="internal" src="https://mdn.mozillademos.org/files/10307/04digsgn.png" style="height: 223px; width: 652px;"></p> - -<p>図 1 は、署名されたデータの受信者に転送される 2 つのアイテムを示しています。元のデータと電子署名は、基本的に署名者の秘密鍵で暗号化された (元のデータの) 一方向ハッシュです。データの整合性を検証するために、受信側のソフトウェアはまず署名者の公開鍵を使ってハッシュを復号化します。次に、元のハッシュを生成したのと同じハッシュアルゴリズムを使用して、 同じデータの新しい一方向ハッシュを生成します。(使用されたハッシュアルゴリズムに関する情報は、図には示されていませんが、電子署名と一緒に送信されます)。最後に、受信側のソフトウェアは新しいハッシュを元のハッシュと比較します。2つのハッシュが一致していれば、データは署名された時から変わっていないことになります。もし一致しない場合は、署名されてからデータが改ざんされているか、署名者が提示した公開鍵とは異なる秘密鍵で署名が作成されている可能性があります。</p> - -<p>2つのハッシュが一致する場合、受信者は、電子署名を復号化するために使用された公開鍵が、電子署名を作成するために使用された秘密鍵に対応することを確信することができます。しかしながら、署名者の身元を確認するには、公開鍵が本当に特定の人物やその他の実体のもので あることを確認する何らかの方法も必要です。この方法についての議論は、"<a href="/ja/docs/Introduction_to_Public-Key_Cryptography">公開鍵暗号入門</a>" を参照してください。</p> - -<p>電子署名の重要性は、手書きの署名の重要性に匹敵します。一度あるデータに署名してしまえば、秘密鍵が危殆化していなかったり、所有者のコントロール外にあったりしていないと仮定して、後で署名したことを否定することは困難です。電子署名のこの品質は、高度な否認防止を提供します。つまり、電子署名は、署名者がデータに署名したことを否定することを困難にします。状況によっては、電子署名は手書き署名と同様に法的拘束力があります。</p> - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> - -<ul> - <li>Author(s): Ella Deon Lackey</li> - <li>Last Updated Date: 2012</li> - <li>Copyright Information: © 2012 Red Hat, Inc.</li> - <li>Link: <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System_Common_Criteria_Certification/8.1/html/Deploy_and_Install_Guide/index.html">Red Hat Certificate System Common Criteria Certification 8.1: Deployment, Planning, and Installation</a></li> -</ul> -</div> diff --git a/files/ja/archive/security/encryption_and_decryption/index.html b/files/ja/archive/security/encryption_and_decryption/index.html deleted file mode 100644 index 6af3c056b3..0000000000 --- a/files/ja/archive/security/encryption_and_decryption/index.html +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: 暗号化と復号化 -slug: Archive/Security/Encryption_and_Decryption -tags: - - Security - - Tutorial -translation_of: Archive/Security/Encryption_and_Decryption ---- -<p><span class="seoSummary">暗号化とは、意図した受信者以外には理解できないように情報を変換するプロセスです。復号化とは、暗号化された情報を再び理解できるように変換するプロセスです。</span> 暗号アルゴリズムは暗号とも呼ばれ、暗号化または復号化に用いられる数学的な関数です。ほとんどの場合、2 つの関連する関数が採用され、1 つは暗号化に、もう 1 つは復号化に用いられます。</p> - -<p>ほとんどの最新の暗号技術では、暗号化された情報を秘密にしておく能力は、広く知られている暗号アルゴリズムではなく、暗号化された結果を生成したり、以前に暗号化された情報を復号化したりするために、アルゴリズムと一緒に使用されなければならない鍵と呼ばれる数字に基づいています。正しい鍵を使った復号化は簡単です。正しい鍵を使わない復号化は非常に難しく、場合によっては実用上不可能な場合もあります。</p> - -<p>以下のセクションでは、暗号化と復号化のための鍵の使用について紹介します。</p> - -<ul> - <li><a href="#Symmetric-Key_Encryption">対称鍵暗号</a></li> - <li><a href="#Public-Key_Encryption">公開鍵暗号</a></li> - <li><a href="#Key_Length_and_Encryption_Strength">鍵の長さと暗号化強度</a></li> -</ul> - -<h3 id="Symmetric-Key_Encryption" name="Symmetric-Key_Encryption">対称鍵暗号</h3> - -<p>対称鍵暗号化では、暗号化鍵は復号鍵から計算でき、その逆も可能です。ほとんどの対称アルゴリズムでは、図1に示すように、暗号化と復号の両方に同じ鍵が使用されます。</p> - -<p><img alt="Figure 1. Symmetric-Key Encryption" class="internal" src="https://mdn.mozillademos.org/files/10303/05scrypt2.png" style="height: 125px; width: 443px;"></p> - -<p>対称鍵暗号化の実装は非常に効率的で、ユーザーが暗号化と復号化の結果として著しい時間遅延を経験しないようにすることができます。1つの対称鍵で暗号化された情報は、他の対称鍵では復号化できないため、対称鍵暗号化はある程度の認証を提供します。このように、対称鍵が通信を暗号化するためにそれを使用する2つの当事者によって秘密にされている限り、各当事者は、復号化されたメッセージが意味のあるものであり続ける限り、他の当事者と通信していることを確信することができます。</p> - -<p>対称鍵暗号化は、対称鍵が関係する2つの当事者によって秘密にされている場合にのみ有効です。他の誰かが鍵を発見した場合、機密性と認証の両方に影響します。未承認の対称鍵を持つ人は、その鍵で送信されたメッセージを復号化できるだけでなく、新しいメッセージを暗号化して、あたかも元々鍵を使用していた2つの当事者のどちらかから来たかのように送信することができます。</p> - -<p>対称鍵暗号化は SSL プロトコルにおいて重要な役割を果たしており、TCP/IP ネットワーク上での認証、改ざん検知、暗号化に広く使用されています。SSL は公開鍵暗号化の技術も使用していますが、これについては次のセクションで説明します。</p> - -<h3 id="Public-Key_Encryption" name="Public-Key_Encryption">公開鍵暗号</h3> - -<p>公開鍵暗号化の最も一般的に使用されている実装は、RSA Data Security が特許を取得したアルゴリズムに基づいています。したがって、このセクションでは公開鍵暗号化に対する RSA のアプローチについて説明します。</p> - -<p>公開鍵暗号化(非対称暗号化とも呼ばれる)では、電子的に身元を認証したり、データに署名したり暗号化したりする必要があるエンティティに関連付けられた公開鍵と秘密鍵のペアの鍵を使用します。それぞれの公開鍵は公開され、対応する秘密鍵は秘密にされます。公開鍵で暗号化されたデータは、秘密鍵でのみ復号化できます。図2は、公開鍵暗号化の仕組みを簡略化したものです。</p> - -<p><img alt="Figure 2. Public-Key Encryption" class="internal" src="https://mdn.mozillademos.org/files/15760/06pcrypt-corrected.png" style="height: 125px; width: 443px;"></p> - -<p>図2のスキームでは、公開鍵を自由に配布することができ、自分だけがこの鍵で暗号化されたデータを読むことができるようになります。一般的に、暗号化されたデータを誰かに送るには、その人の公開鍵でデータを暗号化し、暗号化されたデータを受け取った人が対応する秘密鍵で復号化します。</p> - -<p>対称鍵暗号化と比較すると、公開鍵暗号化はより多くの計算を必要とするため、大容量のデータには必ずしも適切ではありません。しかし、公開鍵暗号化を使って対称鍵を送信し、それを使って追加のデータを暗号化することは可能です。これが SSL プロトコルで使われているアプローチです。</p> - -<p>偶然ですが、図2に示したスキームの逆も機能します。秘密鍵で暗号化されたデータは、公開鍵でのみ復号化できます。しかし、これは機密データを暗号化するのに好ましい方法ではありません。とはいえ、秘密鍵暗号化は有用です。秘密鍵を使用してデジタル署名でデータに署名することができるからです。これは、電子商取引や暗号化の他の商用アプリケーションでの重要な要件です。Firefox などのクライアントソフトウェアは、公開鍵を使用して、メッセージが秘密鍵で署名されたこと、および署名後に改ざんされていないことを確認できます。"<a href="/ja/docs/Archive/Security/Digital_Signatures">電子署名</a>" では、この確認プロセスがどのように機能するかを説明しています。</p> - -<h3 id="Key_Length_and_Encryption_Strength" name="Key_Length_and_Encryption_Strength">鍵の長さと暗号化強度</h3> - -<p>暗号化アルゴリズムを破るとは、基本的には平文で暗号化されたデータにアクセスするための鍵を見つけることです。対称的アルゴリズムの場合、アルゴリズムを破るということは、通常、テキストを暗号化するために使用される鍵を決定しようとすることを意味します。公開鍵アルゴリズムの場合、アルゴリズムを破るということは、通常、2人の受信者間で共有されている秘密情報を取得することを意味します。</p> - -<p>対称アルゴリズムを破る方法の1つは、正しい鍵が見つかるまで、完全なアルゴリズム内のすべての鍵を単純に試すことです。公開鍵アルゴリズムの場合、鍵ペアの半分は公開されているので、残りの半分(秘密鍵)は、複雑ではあるが公開されている数学的計算を使って導き出すことができます。アルゴリズムを破るための鍵を手動で見つけることは、ブルートフォース攻撃と呼ばれます。</p> - -<p>アルゴリズムを破ると、個人情報を傍受したり、個人情報になりすまして不正に検証したりするリスクが発生します。</p> - -<p>アルゴリズムの鍵の強度は、アルゴリズムを破る最速の方法を見つけ出し、総当たり攻撃と比較することで決定されます。</p> - -<p>対称鍵の場合、暗号化の強さは暗号化を実行するために使用される鍵の大きさや長さで表されることが多い。鍵の長さはビット単位で表される。たとえば、SSL でサポートされている RC4 の対称鍵暗号で使用する 128 ビットの鍵は、同じ暗号で使用する 40 ビットの鍵よりも格段に優れた暗号保護を提供します。大まかに言えば、128 ビットの RC4 暗号化は 40 ビットの RC4 暗号化の 3 x 10<sup>26</sup> 倍の強度があります。(RC4 と SSL で使用される他の暗号についての詳細は、"<a href="/ja/docs/Introduction_to_SSL">SSL 入門</a>" を参照してください)。暗号化鍵は、鍵を破るための最良の既知の攻撃が、あらゆる鍵の可能性をテストするためのブルートフォースの試みよりも速くない場合、完全な強さとみなされます。</p> - -<p>異なる暗号化方式では、同じレベルの暗号化強度を達成するために異なる鍵長を必要とする場合があります。例えば、公開鍵暗号化に使用される RSA 暗号は、それがベースになっている数学的な問題の性質上、ある長さの鍵に対して可能なすべての値のサブセットしか使用できません。対称鍵暗号化に使用されるような他の暗号化方式は、それらの値のサブセットではなく、与えられた長さの鍵に対して可能なすべての値を使用することができます。</p> - -<p>RSA 鍵を破ることは比較的簡単なので、RSA 公開鍵暗号化暗号は非常に長い鍵を持たなければなりません。一方、対称鍵暗号は、ほとんどのアルゴリズムで80ビットの鍵でほぼ同じレベルの強度を達成することができます。</p> - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> - -<ul> - <li>Author(s): Ella Deon Lackey</li> - <li>Last Updated Date: 2012</li> - <li>Copyright Information: © 2012 Red Hat, Inc.</li> - <li>Link: <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System_Common_Criteria_Certification/8.1/html/Deploy_and_Install_Guide/index.html">Red Hat Certificate System Common Criteria Certification 8.1: Deployment, Planning, and Installation</a></li> -</ul> -</div> diff --git a/files/ja/archive/security/index.html b/files/ja/archive/security/index.html deleted file mode 100644 index 14e17d366e..0000000000 --- a/files/ja/archive/security/index.html +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Security -slug: Archive/Security -tags: - - NeedsTranslation - - TopicStub -translation_of: Archive/Security ---- -<p><strong><span class="seoSummary">Relying on these obsolete security articles is highly discouraged. Doing so may put your systems at risk.</span></strong></p> - -<p></p><div class="row topicpage-table"> - <div class="section"><dl><dl><dt class="landingPageList"><a href="/ja/docs/Introduction_to_Public-Key_Cryptography">Introduction to Public-Key Cryptography</a></dt><dd class="landingPageList"></dd></dl></dl></div> - <div class="section"><dl><dt class="landingPageList"><a href="/ja/docs/Introduction_to_SSL">Introduction to SSL</a></dt><dd class="landingPageList"></dd></dl></div> - </div><p></p> diff --git a/files/ja/archive/security/threats/index.html b/files/ja/archive/security/threats/index.html deleted file mode 100644 index 54e16b1c57..0000000000 --- a/files/ja/archive/security/threats/index.html +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: 脅威 -slug: Archive/Security/Threats -tags: - - Beginner - - Security - - Tutorial -translation_of: Archive/Security/Threats ---- -<div class="summary"> -<p>この記事では脅威とは何か、そしてどのようにネットワークトラフィックに影響を及ぼすのかを説明します。</p> -</div> - -<p>脅威とは、システムに不正アクセス・漏洩・破壊・改ざん・サービス拒否によってシステムに悪影響を及ぼす潜在的な状況や事象を指します。脅威は故意の人物(サーバの情報にアクセスを目論む攻撃者など)や過失の人物(元社員のユーザアカウントの凍結を忘れた管理者など)が含まれることがあります。脅威は、不満を持つ従業員だったり、別の地理的エリアに居る攻撃者だったりと限定的にもできます。</p> - -<p>脅威の原因には敵対的なサイバー攻撃・物理的攻撃・人為的ミスや組織管轄内外でのハードウェアまたはソフトウェアの障害などがあります。また脅威によって生じる現象は、潜在的な脅威の原因によって引き起こされ、発生した事象を指します。</p> - -<p>データやリソースに対する多くの脅威はOSやのバグや悪用可能な脆弱性を生み出すアプリケーション・ユーザや管理者の人為的ミスによって起こります。 </p> - -<p>ネットワークトラフィックは基本的にルータのような中継コンピュータや無線ホットスポットのような安全でないネットワークを通ります。これによって第三者が間に割り込むことが可能です。このネットワークトラフィックに対する脅威には以下のようなものが挙げられます。</p> - -<ul> - <li><strong>盗聴</strong> 情報は損なわれませんがプライバシーが侵害されます。例えば、誰かがあなたのクレジットカードの番号や記録などの機密情報を窃取・記録できることがこれに当たります。</li> - <li><strong>改ざん</strong> 送信途中の情報を書き換えたり、すりかえて受取人に送信することです。例えば誰かが注文票をすりかえたり、他人の履歴書を書き換えることがこれに当たたります。</li> - <li><strong>偽装</strong> 情報が意図した受取人とは別の人に送られてしまうことです。偽装の手口には2つの方法があります。 - <ul> - <li><strong>成りすまし</strong> 別の誰かのふりをします。例えば<code><a class="link-mailto" href="mailto:jdoe@example.net" rel="freelink">jdoe@example.net</a></code> のアドレス持っている人のふりをしたり、コンピュータを <code>www.example.net</code> のサイトとして認識させたりすることがこれに当たります。このような偽装方法は成りすましとして知られています。</li> - <li><strong>詐称</strong> 人や組織が自分自身を偽る事を指します。例えば <code>www.example.net</code> で家具通販サイトのふりをしてクレジットの支払いを受け付け情報を手に入れるが実際には商品は送らないといったことがこれに当たります。</li> - </ul> - </li> -</ul> - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> - -<ul> - <li>Author(s): Ella Deon Lackey</li> - <li>Last Updated Date: 2012</li> - <li>Copyright Information: © 2012 Red Hat, Inc.</li> - <li>Link: <a class="external external-icon" href="https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System_Common_Criteria_Certification/8.1/html/Deploy_and_Install_Guide/index.html">Red Hat Certificate System Common Criteria Certification 8.1: Deployment, Planning, and Installation</a></li> -</ul> -</div> - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> - -<ul> - <li>Author(s): Joint Task Force Transformation Initiative</li> - <li>Title: National Institute of Standards and Technology (NIST) Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments</li> - <li>Last Updated Date: September 2012</li> - <li>Copyright Information: This document is not subject to copyright.</li> -</ul> -</div> - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> - -<ul> - <li>Author(s): Karen Scarfone, Wayne Jansen, and Miles Tracy</li> - <li>Title: National Institute of Standards and Technology (NIST) Special Publication 800-123, Guide to General Server Security</li> - <li>Last Updated Date: July 2008</li> - <li>Copyright Information: This document is not subject to copyright.</li> -</ul> -</div> - -<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p> diff --git a/files/ja/archive/security/vulnerabilities/index.html b/files/ja/archive/security/vulnerabilities/index.html deleted file mode 100644 index 6d027ffa6e..0000000000 --- a/files/ja/archive/security/vulnerabilities/index.html +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: 脆弱性 -slug: Archive/Security/Vulnerabilities -tags: - - Beginner - - Security - - Tutorial -translation_of: Archive/Security/Vulnerabilities ---- -<div class="summary"> -<p>この記事では脆弱性の説明と脆弱性が全てのシステムにどのように存在しているのかについて説明します。</p> -</div> - -<p>脆弱性は機密性・完全性・可用性に悪影響を与えるシステムの弱点です。脆弱性を分類する方法は多くあります。この記事ではソフトウェアの欠陥・セキュリティ構成の問題・ソフトウェア機能の悪用の3つの高レベルの脆弱性分類に分けて説明します。</p> - -<h2 id="脆弱性分類">脆弱性分類</h2> - -<p>ソフトウェアの欠陥による脆弱性はソフトウェアの設計・実装とは意図しないエラーを引き起こします。例えばユーザから入力された悪意のある文字列が正しく評価できない場合や既知の攻撃に関連する値が長すぎるなどの入力検証のエラーがそれに当たります。もう1つの例は攻撃者に昇格された権限で特定の動作をさせてしまう競合状態のエラーがあります。</p> - -<p>セキュリティ構成の設定はソフトウェア自身のセキュリティを変更するための要素です。例えばユーザがファイルに対して持つ権限を設定するコントロールリストへのアクセスを提供するOSやアプリケーションによって保存された機密データの暗号化を有効・無効にする設定を提供するアプリケーションがそれに当たります。セキュリティ構成の問題による脆弱性はソフトウェアのセキュリティに悪影響を及ぼすセキュリティ構成の設定を伴います。</p> - -<p>ソフトウェアの機能はソフトウェアによって提供される機能的能力です。ソフトウェア機能の悪用による脆弱性はシステムのセキュリティを脅かします。これらの脆弱性はソフトウェア設計者がソフトウェアへの信頼を仮定して便利な機能を設計する一方で、誰かがその信頼が仮定された機能を悪用してセキュリティを侵害することによって引き起こされます。例えば、メールクライアントソフトウェアは電子メール内のHTMLコンテンツをレンダリングする機能を持っていることがあります。攻撃者はハイパーリンクを持つ不正な電子メールメッセージを作成し、HTMLをレンダリングしたときには受取人には良性に見えるもののハイパーリンクをクリックしたときに悪性のウェブサイトへと遷移させる方法があります。HTMLコンテンツレンダリングの設計における信頼の仮定の1つは、ユーザが悪意のあるハイパーリンクを受取ってもクリックしないことでした。</p> - -<p>ソフトウェア機能の悪用による脆弱性(悪用の脆弱性)はソフトウェアまたはソフトウェアのコンポーネント(例えばソフトウェア実装で使用するプロトコル)の設計中に入り込みます。信頼の仮定は明示的であるかもしれません。設計者がセキュリティ上の弱点に気づいていて、他のセキュリティ制御がこれを補償しているかもしれません。しかし信頼の仮定はしばしば黙示的で、最初に導入リスク評価をせずに機能を作り導入していたりします。脅威はソフトウェアの寿命やソフトウェア内で使われているプロトコルによっても変化する可能性があります。例えばARP(Address Resolution Protocol)はARP応答には正しいMACアドレスとIPアドレスの対応が含まれていることが信頼の仮定です。ARPキャッシュはその情報を使ってローカルネットワーク内のデバイス間でデータを送信できるようにし、便利なサービスを提供します。しかし攻撃者が偽のARPメッセージを生成し、システムのARPテーブルを汚染してDoS攻撃や中間者攻撃を行う可能性もあります。ARPプロトコルは25年以上前に標準化され、それ以来脅威は大きく変化しました。そのため、設計時の信頼の仮定は今日でも合理的ではないでしょう。</p> - -<p>ソフトウェア機能の悪用による脆弱性を他の2つの分類と差別化するのは難しいでしょう。例えば、ソフトウェアの欠陥と悪用の脆弱性はソフトウェア設計過程での不備によって生じる可能性があります。しかし、ソフトウェアの欠陥は純粋に悪影響のみを与えます。セキュリティや機能性に良い影響は何もありません。対してソフトウェア機能の悪用は追加の機能を提供した結果として生じます。</p> - -<p>設定やセキュリティ構成の問題に対して、有効・無効を設定できる機能の脆弱性悪用に関して、混乱する点があるかもしれません。主な違いは機能の脆弱性の悪用は機能全体の有効・無効を設定するということで、セキュリティ構成の問題のようにソフトウェアのセキュリティに関わる部分だけを変更するというわけではありません。例えば電子メールの全てのHTML使用を無効化することはセキュリティにも機能にも多大な影響を及ぼします。そのため、この設定に関連する脆弱性は悪用の脆弱性といえます。電子メールクライアントのフィッシング防止機能を無効にすることはセキュリティにのみ多大な影響を及ぼします。そのためこの設定はセキュリティ構成の問題による脆弱性に関連しているといえます。</p> - -<h2 id="脆弱性の存在">脆弱性の存在</h2> - -<p>100%安全なシステムは存在しません。全てのシステムに脆弱性は潜在しています。常にシステムに既知のソフトウェアの欠陥はないかもしれませんが、セキュリティ構成の問題と悪用の脆弱性は常に存在しています。悪用の脆弱性はソフトウェア機能にはつきもので、各々の機能は信頼の仮定に基づいている必要があり、場合によっては大幅なコストと労力を伴うものの、この仮定は壊される可能性があるためです。セキュリティ構成の問題もまた避けられないものです。理由は2つあります。理由の1つは多くの設定機能は機能性を犠牲にセキュリティの向上を行うということです。そのため、ほとんどの安全な設定はソフトウェアを不便にしたり、使い物にならなくしてしまいます。もう1つの理由は多くのセキュリティ設定はセキュリティに対して良い面と悪い面の両方を持つということです。例えば、認証試行の連続した失敗回数によってアカウントがロックアウトされることがそれにたります。ロックアウトするまでの失敗回数を1回にしてしまうことがパスワード推測攻撃に対する最高のセキュリティ設定でしょうが、これでは正しいユーザでもたった1回の打ち間違いでロックアウトされる上、攻撃者がわざと1回認証に失敗するだけでロックアウトさせ、ユーザに対するDoS攻撃に利用されてしまうことも起こり得ます。</p> - -<p>セキュリティ構成の問題や機能の悪用・ソフトウェアの欠陥の可能性は常に付きまといます。そのため1つのシステムには数十~数百の脆弱性が存在する可能性があります。これらの脆弱性は幅広い種類の特徴を持っています。悪用が容易なものもあれば、到底起こり得ないような特定の条件下で悪用できる脆弱性もあります。管理者権限でのアクセスを許してしまう凶悪なものもあれば、大して重要でないファイルを読める程度の脆弱性もあります。結局のところ、組織は脆弱性の悪用容易性・脆弱性が及ぼす可能性のある影響を理解しておく必要があります。</p> - -<div class="originaldocinfo"> -<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> - -<ul> - <li>Author(s): Elizabeth LeMay, Karen Scarfone, and Peter Mell</li> - <li>Title: National Institute of Standards and Technology (NIST) Interagency Report 7864, The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities</li> - <li>Last Updated Date: July 2012</li> - <li>Copyright Information: This document is not subject to copyright.</li> -</ul> -</div> - -<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p> |
