#author("2020-07-23T12:51:00+09:00","","")
[[情報システム開発契約のセキュリティ仕様作成のためのガイドライン（案）]]
*コンテンツの更新中です。 [#r1edeee1]
*目的 [#n21da594]
情報システムの認証方式設計は非常に重要です。一方で、近年、認証方式ごとの課題や脆弱性に関する研究が進み、従来、安全と解されていた運用が、実は脆弱性を招く可能性があることが分かってきました。例えば、2017年に改訂された米国国立標準技術研究所（NIST）の電子認証ガイドライン (SP800-63B) では、従来、必要とされてきたパスワードの複雑性や定期変更に関しては非推奨（SHOULD NOT）とし、パスワードには、辞書に含まれるワードや繰り返しまたは連続した文字を含ませないことを厳格に要求（SHALL）しています。~
本項では、こうした技術動向を踏まえ、システム特性に応じた認証方式を実装するために、認証方法式ごとの技術的な課題や研究成果を整理し、認証方式設計を支援するための解説を行います。
*パスワードの要件と課題 [#gaf01c39]
始めにNIST SP800-63Bからパスワードに対する要求事項（抜粋）をあげ、変更の理由となった研究を後述します。SP800-63BではパスワードやPINを「記憶シークレット」と呼んでいますが、ここでは、パスワードに置き換えています。
**NIST SP800-63-3の記憶シークレット（パスワード）の要求事項 [#zed3bab3]
一般的にはパスワードや、数字ならばPinとして表されているものは、ユーザーによって決められ、記憶されるシークレットである。パスワードは攻撃者が正しい値を推測したり特定できないように、十分な複雑かつ秘密の状態にしておく必要がある。
-ユーザーが指定する場合、最低8文字以上を要求する (SHALL)
ｰパスワードの設定、変更を処理する際、一般的に利用されているパスワード、予想できるパスワード、セキュリティ侵害を受けたパスワードと比較する (SHALL)
--過去にセキュリティ侵害にあったパスワードリスト
--辞書に含まれる言葉
--サービス名や、ユーザー名、そこから派生するようなものなど、文脈によって特定可能な単語
-パスワードがこれらに該当したらユーザーは異なるパスワードを選びなおす必要があることを通知され、異なる値の選択を求められる (SHALL)
-アカウント乗っ取りのために試みた認証失敗の回数を制限する仕組みを実装する (SHALL)
-例えば異なる文字種の組合せをパスワードに課すべきではない (SHOULD NOT)
-パスワードが侵害されている、ユーザーの変更要求がない限り、パスワードを例えば定期的に変更するよう要求するべきではない (SHOULD NOT)
-パスワード入力時にペースト機能を利用できることを許可すべき (SHOULD)
&br;
>「SHALL（するものとする）」及び「SHALL NOT（しないものとする）」というキーワードは、刊行物に厳密に従うことを要求しており、内容と異なってはならない。
>「SHOULD（すべきである」」及び「SHOULD NOT（すべきではない）」は、いくつかある選択肢の中で特定の推奨があることを示しており、他の選択肢については選択も除外もしない。ある行動指針を推奨するが、必須であることまでは要求しない。（否定の意味では）ある選択肢または行動指針を非推奨するが、禁止はしない。
>「MAY（してもよい）」及び「NEED NOT（しなくてよい）」は、刊行物の範囲において、行動指針が許容できることを示す。
>「CAN（できる）」及び「CANNOT（できない）」は、可能性や、能力があることを示す。その対象が物理的か一時的かにはかかわらない。
**パスワードの課題 [#f0d32f77]
本項では、NIST SP800-63Bが要求事項改訂に至ったとする課題について解説します。
***長さについて [#wcf79e92]
NISTとカーネギーメロン大学の研究で、5,000人の参加者に、様々なパスワードを生成させ、その強度を比較したところ、「8文字」・「複雑さ」・「辞書に含まれていない」パスワードよりも、何ら制約を課していない16桁のパスワードが優れていたことが判明しました。パスワードの適切な長さについては、システムの特性によるとしていますが、短すぎるパスワードは辞書攻撃や総当たり攻撃に弱いため、最低8文字とされています。また、長いパスワードが使えるように促進されるべきとしています。~
Of Passwords and People:Measuring the Effect of Password-Composition Policies : https://users.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwords.pdf
***複雑さの課題 [#z6e272b3]
複雑さとは、以下の複数の文字種の使用を条件とするもので、通常、3種類か4種類の使用を求めます。
-英大文字
-英小文字
-数字
-記号（特殊文字）
複雑さは攻撃の困難性を高める有効な手段として考えられていましたが、複雑さを求めることで別な弊害が発生することが研究で明らかになっています。ユーザーは複雑さを条件とされると、比較的高い確率で以下のような遷移を遂げました。
最初のパスワード password
大文字、小文字、数字の要求 Password1
大文字、小文字、数字、記号の要求 Password1!
このように複雑さを強制してもパスワードの推測が可能であり、強度の向上にはつながらないことが判明しています。~
また、別の研究では、長さが8桁で複雑さを条件とした場合、制約から1桁から7けたまでの組み合わせと、大文字・小文字・数字・記号以外の組合せ（約40%）は除外されるため、8桁の制約なしの組み合わせ数は60兆よりも少ない、36兆の組合せだけが有効となり、推測困難性を下げる結果となります。
***複雑さの課題 [#e9e1bd87]
複雑さとは、以下の複数の文字種の使用を条件とするもので、通常、3種類か4種類の使用を求めます。
-英大文字
-英小文字
-数字
-記号（特殊文字）
複雑さは攻撃の困難性を高める有効な手段として考えられていましたが、複雑さを求めることで別な弊害が発生することが研究で明らかになっています。ユーザーは複雑さを条件とされると、比較的高い確率で以下のような遷移を遂げました。~
最初のパスワード password
大文字、小文字、数字の要求 Password1
大文字、小文字、数字、記号の要求 Password1!
このように複雑さを強制してもパスワードの推測が可能であり、強度の向上にはつながらないことが判明しています。~
Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords : http://www.cs.umd.edu/~jkatz/security/downloads/passwords_revealed-weir.pdf~
また、別の研究では、長さが8桁で複雑さを条件とした場合、制約から1桁から7けたまでの組み合わせと、大文字・小文字・数字・記号以外の組合せ（約40%）は除外されるため、8桁の制約なしの組み合わせ数は60兆よりも少ない、36兆の組合せだけが有効となり、推測困難性を下げる結果となります。
***定期変更の課題 [#y80f591e]
パスワードの定期変更を求めると、多くのユーザーでパスワードの末尾の記号を増やしたり減らすなどの推測可能なパスワードを生成することが分かっています。米国での大規模な研究 では、11%のアカウントで過去のパスワードが分かれば、5回未満で現在のパスワードを入手できました。これは、5回でロックアウトするシステムの場合、11%のユーザーはオンラインでクラックされてしまう、という事を意味します。また、オフラインの場合は、数秒で40%を超えるユーザーの現在のパスワードを割り出に成功しています。~
安易な類推可能なパスワードを増やすだけであれば、定期変更を求めず、パスワードが危殆化した時だけ、変更するのは合理的といえます。~
なお、パスワードに有効期限を設けて定期的に変更を強制する理由として、「パスワードが侵害された場合に備える」があります。しかし、パスワードが侵害されたならば、即座に変更をするべきで、次の定期変更日まで待つ必要はなく、そもそも定期変更の理由にはなっていません。~
The Security of Modern Password Expiration:An Algorithmic Framework and Empirical Analysis : https://www.cs.unc.edu/~reiter/papers/2010/CCS.pdf
***パスワードの使い回しの課題 [#bd1a7ac6]
パスワードの使い回しは危険だという指摘は多数ありますが、さまざまなWebサイトごとにパスワードを変えて、それを覚えるのは大変ですし、いざ必要な時に素早くアクセスできないのはさらに苦痛です。こうしたことから、多くのユーザーはパスワードを使い回します。~
それを防止させるため、SP800-63B ではパスワードの入力の際にペーストを許可し、これにより、パスワードマネージャーの利用を促進し、強力なパスワードを選択できる可能性を増加させる、としています。
*他の認証の課題 [#ra4f0724]
パスワード以外の認証方式にも課題や脆弱性の指摘を解説します。また、認証に関わる留意事項も解説します。
**スマートカードログオンに関する課題 [#i7f6e94a]
スマートカードは多要素認証の代表格であり、単一認証に比べればはるかに強固な認証ソリューションを提供します。スマートカード（所有）とPIN（知識）という組み合わせが必要なため、たとえPINが漏洩してもスマートカードがなければ攻撃が成功しないとされています。~
しかし、スマートカードログオンでも、Windowsの場合はNTLMハッシュを生成されることから、NTLMハッシュを悪用するPass The Hash攻撃に対して万全という事はいえません。NTLMハッシュが窃取されてしまえばスマートカードがなくてもログオンは成功します。従って、スマートカードアカウントの定期的なハッシュのローテーションは必須であり、Credential Guard などのソリューションを組み合わせることで、NTLMハッシュを保護しなければ、期待される効果が発揮されません。~
また、紛失や盗難があった場合、スマートカード再発行までの期間、代替の認証方式を用意する必要があり、また、安全な物理的配布と本人確認などの課題があります。
3.2 生体認証に関する課題
生体認証は顏、指紋、静脈などの生体情報を使った認証であり、スマートカード（所有）やハードウェアワンタイムパスワード（所有）に比べて持ち歩く必要がなく、紛失や盗難などが起こらないというメリットがあります。しかし、生体情報が漏洩した場合、代替が困難なことから、認証側での生体情報の保持を厳重にする必要があります。また、生体認証は誤認識による他人認識や本人拒否があり、確率的な認証方式といえます。重要な情報資産を操作する際に決定的でなく、確率的であるとことは、他の要素との組み合わせが必須であることから、知識や所有との組み合わせが必須となってきます。~
但し、本人確認の上で引き渡されたスマートフォン（所有）と顔認証（生体）とPIN（知識）は強固であり、今後、期待できる認証方式といえます。
**その他の認証に関する留意点 [#t2d74935]
***E-Mailは経路外認証とはならない [#xcc6d28d]
NIST SP800-63-Bでは、スマートフォンを使った経路外認証が当初は非推奨となり、最終的には ”RESTRICTED” となりました。事前登録済の電話番号が物理デバイスと結びついていることを確認した上で、AuthenticatorやSMSにワンタイムパスワードを送信することは問題ありませんが、E-Mail を使った場合は、特定デバイスの所有の証明とはならないため経路外認証とは認められません。
***デフォルトのIDは必ず変更する [#wddfda8a]
Administrator、Admin、Adm、root、Su などの、OS、データベース、通信機器などのデフォルトのIDは、総当たり攻撃の際に使用されるため、変更可能な場合は、初期設定時に必ず変更しておく必要があります。IDを変更できれば、総当たり攻撃に対する耐性が確保できます。
***開発者のIDは削除する [#pdb7efb7]
開発中に使用した開発者のID、テスト用のIDなど、運用に不要なIDは必ず削除してください。
***Machine To Machine [#g5bacb0b]
機器同士の通信の場合、IDやパスワードがハードコードされるケースが散見されますが、危険です。アクセス権限が設定された外部ファイルに暗号化して保存するなど、変更したい場合にはいつでも変更できるような構成が必要です。また、デフォルトのIDのまま初期設定されると、前項同様に総当たり攻撃に対して脆弱となりますので、導入設置時には変更を強制する認証システムの実装が必要です。~
PKIを使用する際は、証明書の有効期限切れのないように期限管理に留意してください。
***特権ID、パスワードの保管 [#oa80ce64]
管理者のID、パスワードなどを保管する場合は、オフラインが原則です。サーバーや端末には保存せず、CD-ROM等の外部メディアに保存し、CD-ROMケースに封緘して鍵のかかる金庫に保管してください。紙に記録した場合も、同様に封筒に入れて封緘し鍵のかかる金庫に保管します。
***ID、パスワード、センシティブ情報のハードコードの禁止 [#ac76e011]
ID、パスワードやセンシティブな情報をソースコートに直接書き込まないでください。ハードコードされたID、パスワードなどはプロジェクトに参加した開発者全員が知ることとなり、運用に入った後で、パスワードが危殆化した場合、ソフトウェアをバージョンアップする必要が出ます。攻撃者がバイナリにアクセスできる場合、逆アセンブルすることでID、パスワードなどの漏洩につながります。対策として、JPCERT/CCの実装例 を参照してください。~
OSSのソースを受け入れる際は、ハードコードされたID、パスワードの存在を確認し、認証ロジックを実装してください。また、ハードコードしたソースをGit Hubなどで公開しないようにしてください。~
アプリケーションが使用するユーザーやシステムIDは、Service Principal Name (SPN) を使用し、一般ユーザーアカウントを使用しないでください。
***長いパスワードを実装する場合 [#jd09f426]
パスワードの組み合わせは、以下の式で得られます。 ~
組み合わせ数＝bn
ここで、b は利用可能な文字種であり、標準的な101キーボードではスペースを含めると95種類が利用可能です。パスワードの桁数が6桁であれば、735,091,890,625の組合せがあり、8桁ならば6,634,204,312,890,620と格段に多い組み合わせが考えられます。べき乗であることから、1桁増えれば95倍組み合わせが増えるため、桁数を長めにすることで総当たり攻撃を困難にすることが可能となります。
&br;
|BGCOLOR(NAVY):COLOR(WHITE):CENTER:桁数|BGCOLOR(NAVY):COLOR(WHITE):CENTER:組み合わせ数|h
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:1|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:95|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:2|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:9,025|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:3|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:857,375|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:4|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:81,450,625|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:5|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:7,737,809,375|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:6|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:735,091,890,625|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:7|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:69,833,729,609,375|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:8|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:6,634,204,312,890,620|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:9|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:630,249,409,724,609,000|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:10|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:59,873,693,923,837,900,000|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:12|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:540,360,087,662,637,000,000,000|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:14|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:4,876,749,791,155,300,000,000,000,000|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:16|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:44,012,666,865,176,600,000,000,000,000,000|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:18|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:397,214,318,458,219,000,000,000,000,000,000,000|
|BGCOLOR(WHITE):COLOR(BLACK):CENTOR:20|BGCOLOR(WHITE):COLOR(BLACK):RIGHT:3,584,859,224,085,420,000,000,000,000,000,000,000,000|
&br;
但し、ユーザーに長いパスワードを求めると次のような弊害が発生します。~
-文字列の繰り返し 12341234、monkeymonkey、monkeyeknom
-連続した文字列 111111111･･･ qwerty･･･~
繰り返しや連続した文字列は、機械的に攻撃用の辞書データを作成できることから、好ましくありません。ある程度の長さを要求する場合は、これらの弊害を取り除くロジックの実装が必要になります。これは、長いパスフレーズを利用する上でも、同様です。
[[認証方式設計の検討とパスワード認証の要求事項]]
*パスワードに関する技術的な動向と本ガイドラインの見解 [#k014502e]
パスワード認証に関するガイダンスは多数あり、さまざまな見解が公表されています。
|160|80|60|60|100|70|100|c
|タイトル|桁数|辞書検査|複雑さ|定期変更|使いまわし|多要素|h
|[[内閣サイバーセキュリティセンター インターネットの安心・安全ハンドブック:https://www.nisc.go.jp/security-site/files/handbook-all.pdf]]|10桁以上|ー|英大小数字記号|必要なし、流出時に速やかに変更|不可|推奨|
|[[総務省 国民のための情報セキュリティサイト:https://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/privacy/01-2.html]]|適切な長さ|推奨|英数|必要なし、流出時に速やかに変更|不可|ー|
|[[IPA 今、パスワードが危ない！チョコっとプラス パスワード:https://www.ipa.go.jp/chocotto/pw.html]]|8文字以上|推奨|英大小数字記号|ー|不可|ー|
|[[NIST SP800-63B Digital Identity Guidelines:https://www.jipdec.or.jp/sp/topics/event/u71kba0000009o56-att/nist_sp_800-63b.pdf]]|8文字以上|必須|不要|不要|不可|システム特性に応じて必須|
|[[OWASP Application Security Verification Standard V4:https://owasp.org/www-project-application-security-verification-standard/]]|12文字以上|必須|不要|不要|不可|システム特性に応じて必須|
|[[国防総省 STIG Windows Server 2016:https://www.stigviewer.com/stig/windows_server_2016/]]|15|必須|英大小数字記号|60日以下|不可|必須|
|[[Microsoft Password Guidance:https://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/Microsoft_Password_Guidance-1.pdf]]|8文字以上|必須|不要|不要|不可|必須|
|[[Google 強力なパスワードとより安全なアカウントを作成する:https://support.google.com/accounts/answer/9094506]]|8文字以上|推奨|許容|ー|不可|ー|
&br;
**NIST SP800-63B [#h5656284]
この中でも、米国国立標準技術研究所（NIST) の電子認証ガイドライン(SP800-63-3) は、影響力が強く、OWSP Application Security Verification Standard V4 はSP800-63-3に準拠済みで、クレジットカード業界のセキュリティ規格である PCIDSS も NIST の見解を反映させた新しいバージョンを2020年後半にリリースするとしており、今後、SP800-63-3 がデジタル認証の標準の地位を占めるものと考えられます。~
SP800-63-3は、以下の特徴的な改訂を行っています。（以下、SHALL は必須要件、SHOULD は必須ではないが推奨要件、SHOULD NOT は必須ではないが非推奨要件を示します。）
-システムがランダムにパスワードを決定する場合最低6文字(SHALL)
-ユーザがパスワード決定する場合は8文字以上(SHALL)
-以下の要件に該当するか比較し(SHALL）、その場合は、理由を説明し(SHALL）、他のパスワードへの変更を求める(SHALL）
--過去に漏洩した語彙集から得られるパスワード
--辞書に含まれる言葉
--繰り返しまたはシーケンシャルな文字（例： 'aaaaaa'、 '1234abcd'）
--サービス名や、ユーザ名、そこから派生するようなものなど、文脈で特定可能な単語
--他の構成ルール（異なる文字種の組み合わせ等）を課すべきではない（SHOULD NOT）
-定期的変更を求めるべきでない(SHOULD NOT）
-危殆化した証拠がある場合は、変更を強制する(SHALL）
-パスワード強度メーターの推奨（SHOULD）
**パスワードの長さについて [#pc1c0aeb]
NIST SP800-63 （2006/4版、邦訳：https://www.ipa.go.jp/files/000025342.pdf）では、ランダムな94文字種から作成した6桁のパスワードのエントロピー（ばらつき強度）を39.5bitと推定しています。また、ユーザーが選択した場合は、94文字種で、辞書規則（5万語の辞書に掲載されていない）と組み合わせ規則（繰り返しやqwerなどの連続性の排除）を適用した場合のエントロピーを30bitと推測しています。~
一方で、ユーザーが規則の適用なしに自由に選んだ8文字のパスワードの場合、エントロピーは18bitと推測しています。このため、辞書やサービス名の使用を禁止したものと考えられます。
**定期的変更は求めるべきでない（SHOULD NOT） [#md789f0c]
[[2010年のノースカロライナ大学の研究:https://https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes]]で、無効な10,000を超えるアカウントから50,000個のパスワードを入手し分析したところ、調査したアカウントの17％について、ユーザーの以前のパスワードを知っていれば、5回以下で現在のパスワードを推測できることが報告されています。これは、定期変更が求められた際に、文字を数字や記号に換えたり、記号を追加したり削除し、似通ったものを新しいパスワードとして登録する人が多いことを示しており、ロックアウトの有効性が著しく下がることを意味します。オフライン攻撃の場合、攻撃者にとって定期変更は障壁ではなく、かえって安全性を損ねるものという判断がなされています。~
**Microsoft Security Baselines Blogの見解 [#qbe5b57d]
Security baseline (FINAL) for Windows 10 v1903 and Windows Server v1903 で定期変更を推奨しない理由を以下のようにあげています。
-パスワードが盗まれていない場合は、パスワードを期限切れにする（定期変更の）必要はない。
-パスワードが盗まれた証拠がある場合は、有効期限が切れるのを待って問題を解決するのではなく、すぐに対処すべきである。
-組織が禁止するパスワードリスト、多要素認証、パスワード推測攻撃の検出、および異常なログオン試行の検出を正常に実装した場合、定期的なパスワード有効期限は必要だろうか。
-最新の緩和策を導入していない場合、パスワードの有効期限が切れることによって、どの程度の保護が得られるのだろうか。
https://techcommunity.microsoft.com/t5/microsoft-security-baselines/security-baseline-final-for-windows-10-v1903-and-windows-server/ba-p/701084
*本ガイドラインの考え方[#t7746579]
本ガイドラインでは、対象システムの特性に応じて認証強度を検討すべきとの立場から、以下を推奨します。
**個人情報、機微情報、知財を取り扱うシステム、VPNなどのネットワーク境界接続での認証には多要素認証を求めるべき [#m872e1a9]
-バックオフィス系システム
-インターネット上のWebシステム
-クラウドの制御コンソール
-SSH接続のための踏み台サーバー (Bastion Server)、VPN
-多要素認証の導入が困難な場合は、代替手段としてパスワードの漏洩のチェック、ロックアウト、ログオン試行の検出などを検討する
-多要素認証は、ハードウェアトークン、ソフトウェアトークン（Authenticator)、メール、SMS による One Time Token などを検討すべき
-デスクトップアプリケーションは、取り扱う情報の性質に応じて、ライツマネジメントや暗号化を検討すべき
-生体認証は確率的であり他人を認証する場合があることから、個人の所有が特定できる携帯電話、デバイス等との組み合わせを検討する
**ID/パスワードの考え方 [#beeb53bf]
-最低8桁とし、複雑さ、定期変更を求めない
-複雑さを求めると推測しやすいパターンができる 例：先頭大文字のキーワード＋数字＋末尾記号
-定期変更は求めないが、漏洩が発覚した際は即時に変更を求める
-特定の文字列の繰り返し、回文は排除する 例：12341234、monkeyyeknom
-IDにメールアドレスを使用する場合や、個人を特定しやすいIDを使う場合、推測可能な生年月日や電話番号をもとにした攻撃が可能なため、英数のセットを要求すべき
-5回以上連続して認証に失敗した場合は、一定期間、内部的にロックアウトを求めるか、パスワード変更を求める~この際、内部的にはロックアウトを実行しておくが、外部からの有効なIDの確認がなされないようにするため、「IDかパスワードが違うためログオンできません」などのメッセージを表示し、ログオンの試行は継続的に許可するなどを検討すべき
**Windows グループポリシーでの例外 [#v9a707d2]
Windows のグループポリシー [コンピューターの構成]>[ポリシー]>[Windows の設定]>[セキュリティの設定]>[アカウントポリシー]>[パスワードのポリシー]及び[アカウントロックアウトのポリシー]については、以下を推奨するとともに、多要素認証の導入を強く推奨します。
***多要素認証を導入しない場合の [パスワードのポリシー] [#lba33e77]
-[パスワードの長さ] は15桁以上を推奨する
-[複雑さの要件を満たす必要があるパスワード] を有効にすることで SamAccountName、DisplayName を ID に含ませることができない事から、有効にする
-定期的なセキュリティログ監査もしくはパスワードの漏洩・侵害検査の導入を前提に、[パスワードの有効期間]は[0日]（定期変更を求めない）、[パスワードの履歴を記録する]は[0回]（パスワードの履歴は求めない）とする
--ログ監査の対象Event ID~
セキュリティログ Event ID:4625（アカウントがログオンに失敗しました）、Event ID:4776（資格情報の確認）
***多要素を導入しない場合の [アカウント ロックアウトのポリシー] [#z5d2aa43]
--[アカウントのロックアウトのしきい値] を[5回ログオンに失敗] とする
--[ロックアウト カウンターのリセット] を [15分後] とする
--[ロックアウト 期間] を [15分] とする
***Windows Hello などの多要素認証を導入した場合 [#x6d14e8e]
--PIN を使用する場合、6桁以上とする
--PIN の定期変更、履歴、複雑性は求めない、但し、個人から推測可能な誕生日、電話番号等の使用は認めず、これらを規程化する
