近年、セキュリティはますます複雑になっています。 攻撃が急増しているため、組織に侵入する簡単な方法は、安全でないアカウントを使用することです。 強力なアカウントパスワードから始めると、大きな違いが生じます。 しかし、セキュリティの多くの側面と同様に、パスワードを強力にするものは何年にもわたって変化しています。
この記事では、強力なパスワードに関する現在の推奨事項と、パスワードマネージャーを使用して組織のサービスアカウントのパスワードを保護する方法について説明します。 最後に、Specops Password Policyなどの製品を使用して、強力なパスワードが会社全体で使用されていることを確認します。
この投稿は親切に後援されています Specopsソフトウェア。
2022年のパスワードのベストプラクティス
多くの組織で使用されている最も重要な推奨事項は、NIST（米国国立標準技術研究所）のドキュメントに記載されているガイドラインです。 800-63B。 2020年3月の時点で最近更新されたガイドラインには、新しい説明と推奨事項が含まれています。
従来、エンドユーザーのパスワードに関する推奨事項は、次のことに焦点を当てる傾向がありました。
- 特殊文字と数字の組み合わせを含む複雑なパスワードの使用。
- パスワードを頻繁にローテーションします。通常は90日ごとです。
- パスワードは長くする必要があり、パスワードは長いほど良いです。
ガイドラインの更新により、以前に保持されていたこれらのテナントの一部が頭に浮かびます。 特に、NISTは、特定の数の特殊文字または数字を必要とする複雑なパスワードの使用を推奨しなくなりました。 実際、ガイドラインには、複雑さの要件はまったく課されていないと記載されています。
この理由は、個人は単純さを優先する傾向があるため、単純であるが潜在的に一意のパスワードよりも複雑さの要件を満たす共有パスワードを再利用するためです。
これは、パスワードローテーションに関する更新にもつながります。NISTでは、侵害がわかっている場合を除いて、パスワードローテーションは不要であると推奨しています。 多くの場合、個人は、一意であるが長持ちするパスワードを使用するのではなく、要件を満たしている既存のパスワードを単純にインクリメントします。
最後に、NISTは、ランダムに割り当てられたパスワードは6文字以上、選択されたパスワードは8文字以上にすることを推奨しています。標準が成熟するにつれて長さの要件が増えると思われますが、この場合、思考プロセスはランダムに割り当てられたパスワードです。 6文字は、顧客が選択した8のパスワードと同様に十分に安全です。
それで、これで、それはエンドユーザーにとって何を意味するのでしょうか？ 新規または更新されたパスワードを入力する場合、理想的なパスワードポリシーとパスワード入力画面は次のようになります。
- 複雑さの要件がない最小8文字のパスワード。 <脇>
ASCII文字、スペース、および正規化（NFKXまたはNFKD）Unicode（ISO / ISC 10646）を許可する必要があります。 - 安全でないことが示されているため、パスワードのヒントはありません。
- ブルートフォーシングを回避するためにレート制限を実装します。
- 貼り付けを許可します。これにより、パスワードマネージャーが強化され、エンドユーザーが入力しているときにパスワードを表示できます。
- 入力時に、既知の安全でないまたは侵害されたパスワードに対してパスワードを確認します。
これらのプロセスの改善により、実際の経験に基づいて、エンドユーザーはより簡単な要件と改善されたユーザーエクスペリエンスの対象になります。
実際のサービスアカウントパスワードの活用
これまではエンドユーザーに焦点が当てられており、上記はすべて堅実な慣行です。 これは、他の一連の課題、特にサービスアカウントのパスワードにとってどのような意味がありますか？ 通常、あまり焦点を当てていないサービスアカウントは、エンドユーザーよりも共有される性質と高い特権があるため、さらに多くのアクセスを提供する場合があります。
それでは、パスワードの慣行はサービスアカウントに対してどのようにすべきですか？ これらは、エンドユーザーのパスワードとまったく同じです。 NISTでは詳しく説明されていませんが、サービスアカウントのパスワードはランダムに生成され、8文字より長くする必要があります。 これらのパスワードは個人が覚える必要がないため、パスワード自体が長く複雑にならない理由はありません。
使用を支援するために、組織レベルでサービスアカウントについて話すときは、パスワードマネージャーが関与する必要があります。 これは実際にはどのように見えるでしょうか？
これは、パスワードマネージャー1Passwordによって駆動される、コマンドラインでサービスアカウントのパスワードを取得するための2つの例と、RESTAPIサービスを介して別の例です。 どちらの手法も一般的なパターンですが、さまざまなユースケースに焦点を当てています。
コマンドラインユーティリティからのパスワードの取得
多くの場合、IT組織は、バックアップやデータ変換などの重要なタスクを実行するスクリプトを利用します。 これらのスクリプト内では、多くの場合、必要なパスワードを取得する必要があります。 従来、パスワードはスクリプト内にプレーンテキストで保存されていました。つまり、悪意のある攻撃者がスクリプトを取得しただけでは、パスワードが盗まれる可能性があります。
これを回避する1つの方法は、パスワードマネージャーからコマンドラインクライアントを使用して、スクリプトの実行中にパスワードを取得することです。 そうすれば、パスワードは保存されず、スクリプトの実行中に一時的に取得および使用されるだけであり、攻撃者が盗むのがはるかに困難になります。
以下は、1Passwordからコマンドラインクライアントを使用してAzure ADに接続するために必要な資格情報を取得し、グループメンバーを取得してCSVファイルにバックアップするPowerShellスクリプトの例です。 ご覧のとおり、スクリプト内にプレーンテキストのパスワードが保存されることはありません。パスワードが変更された場合は、次回の実行時に新しいパスワードが使用されます。
Import-Module -Name "AzureAD"
$Credentials = op item get 'Azure Credentials' --format=json --vault 'ATA Learning' | ConvertFrom-JSON
$Username = $Credentials.fields[0].value
$Password = ConvertTo-SecureString $Credentials.fields[1].value -AsPlainText -Force
[PSCredential]$AzureAdCred = New-Object System.Management.Automation.PSCredential ($UserName, $Password)
Connect-AzureAD -Credential $AzureAdCred
$GroupObjectID = '3c97a54d-ec15-4ace-83fb-38cd16761c4f'
$Members = Get-AzureADGroupMember -ObjectId $GroupObjectID
$Members | Select-Object DisplayName, AccountEnabled | Format-Table -AutoSize
$Members | Export-Csv -Path 'C:WorkingFolderUsers.csv' -Force
RESTAPIを介したパスワードの取得
もちろん、コマンドラインアプリケーションを介してパスワードを取得することが唯一の方法ではありません。 他のアプリケーションでは、RESTAPIを使用する必要があります。 この方法は、追加の実行可能ファイルに依存してはならないアプリケーションまたはスクリプトに適している場合があります。
前のスクリプトと同様に、このバージョンは1PasswordConnectサーバーのRESTAPIを使用して同じ資格情報を取得するように適合されていますが、追加の実行可能ファイルに依存することはありません。
ローカルホストURIの理由は、1PasswordConnectがDockerコンテナとして実行されるためです。 ローカルで実行する場合、これはデフォルトのURIです。
Import-Module -Name "AzureAD"
$Credentials = Invoke-RestMethod -URI ("http://localhost:8080/v1/vaults/{0}/items/{1}" -F 'hhbmehr5aemywegzr3onmijbpm','ejobbzg5pubyonrerogirykota') -Headers @{
'Accept' = 'application/json'
'Authorization' = "Bearer $Token"
}
$Username = $Credentials.fields[0].value
$Password = ConvertTo-SecureString $Credentials.fields[1].value -AsPlainText -Force
[PSCredential]$AzureAdCred = New-Object System.Management.Automation.PSCredential ($UserName, $Password)
Connect-AzureAD -Credential $AzureAdCred | Out-Null
$GroupObjectID = '3c97a54d-ec15-4ace-83fb-38cd16761c4f'
$Members = Get-AzureADGroupMember -ObjectId $GroupObjectID
$Members | Select-Object DisplayName, AccountEnabled | Format-Table -AutoSize
$Members | Export-Csv -Path 'C:WorkingFolderUsers.csv' -Force
ザ
$Token変数は以前に割り当てられていましたが、デモンストレーションとセキュリティの目的でスクリプトから省略されています。
Specopsパスワードポリシーを使用して、パスワード管理のベストプラクティスをエンドユーザーの前に置く
現在、NISTと業界によって概説されているこれらのベストプラクティスはすべて、強力なパスワードポリシーが全体に適用されていない場合は意味がありません。 組み込みのMicrosoftパスワードポリシーとカスタマイズ機能は、多くのセキュリティに重点を置いた組織が必要とするほど包括的ではありません。
パスワードポリシーを強化し、真に次のレベルに引き上げるために、 Specopsパスワードポリシー アカウントを保護するために重要です。
- 侵害されたパスワード保護アドオンを利用して、侵害されたパスワードをリアルタイムでブロックし、定期的な詳細なアカウントスキャンを利用して、追加の侵害されたパスワードを見つけます。
- エンドユーザーまたはサービスアカウントが使用されているかどうかに関係なく、各ユニットの固有の要件を満たすための包括的でカスタマイズ可能なパスワードポリシー。
- 毎回適切なポリシーが適用されるようにするための、ポリシーのきめ細かいターゲティング。
- エンドユーザーが作成時に安全なパスワードを作成することを確認するための、Specops認証クライアントによるリアルタイムのフィードバック。
進化し続けるセキュリティ環境に存在するすべての脅威があるため、特に更新されたNIST標準のコンテキストで安全なパスワードを使用することは、組織のセキュリティを維持するために重要です。 Specops Password Policyなどの製品は、悪意のある攻撃者から組織とアカウントを保護するのに役立ちます。
2022年のパスワード管理
更新されたNIST標準は、パスワードセキュリティの既存の概念を頭に入れていますが、人間の行動や実際の経験の文脈で見ると、ガイドラインは非常に理にかなっています。
のような製品を利用する Specopsパスワードポリシー エンドユーザーからサービスアカウントまでのさまざまなパスワードシナリオを実施するために、組織が存在する多くの外部および内部の脅威から可能な限り安全であることを確認します。 すべての種類のアカウントに最新のパスワードポリシーを適用してセキュリティを次のレベルに引き上げ、それらが全面的に適用されるようにします。
The post 強力なパスワードでエンドユーザーを安全に保つ appeared first on Gamingsym Japan.