Okta Hardening
ディレクトリ
ユーザー
攻撃者の視点からは、登録されたすべてのユーザー、メールアドレス、所属するグループ、プロファイル、さらにはデバイス（モバイルとそれらのOSを含む）を見ることができるため、これは非常に興味深いです。
ホワイトボックスレビューでは、**「保留中のユーザーアクション」と「パスワードリセット」**が複数あるかどうかを確認してください。
グループ
ここにはOktaで作成されたすべてのグループが表示されます。ユーザーに付与できる権限のセットである異なるグループを理解することが興味深いです。 グループに含まれる人々や各グループに割り当てられたアプリを見ることができます。
もちろん、adminという名前のグループは興味深いですが、特にGlobal Administratorsグループは、最も特権を持つメンバーが誰かを知るためにメンバーをチェックしてください。
ホワイトボックスレビューからは、5人以上のグローバル管理者がいないことを確認してください（2人または3人だけの方が良いです）。
デバイス
ここにはすべてのユーザーのデバイスのリストが表示されます。アクティブに管理されているかどうかも確認できます。
プロファイルエディター
ここでは、名前、姓、メール、ユーザー名などの重要な情報がOktaと他のアプリケーション間でどのように共有されているかを観察できます。これは興味深いです。なぜなら、ユーザーがOktaでフィールド（名前やメールなど）を変更できる場合、それが外部アプリケーションでユーザーを識別するために使用される場合、インサイダーが他のアカウントを乗っ取ろうとする可能性があるからです。
さらに、Oktaのプロファイル**User（デフォルト）では、各ユーザーが持っているフィールドとユーザーが書き込み可能**なフィールドを見ることができます。管理パネルが見えない場合は、プロフィール情報を更新して、更新できるフィールドを確認できます（メールアドレスを更新するには確認が必要です）。
ディレクトリ統合
ディレクトリを使用すると、既存のソースから人々をインポートできます。他のディレクトリからインポートされたユーザーをここで見ることができると思います。
私は見たことがありませんが、Oktaがユーザーをインポートするために使用している他のディレクトリを見つけることが興味深いと思います。したがって、そのディレクトリを侵害すると、Oktaで作成されたユーザーの属性値を設定し、Okta環境を侵害する可能性があります。
プロファイルソース
プロファイルソースは、ユーザープロファイル属性の真実のソースとして機能するアプリケーションです。ユーザーは、1回につき1つのアプリケーションまたはディレクトリからのみソース化できます。
私はそれを見たことがないので、このオプションに関するセキュリティとハッキングに関する情報は歓迎します。
カスタマイズ
ブランド
このセクションのDomainsタブで、メールを送信するために使用されるメールアドレスや会社のOkta内のカスタムドメイン（おそらく既に知っているであろうもの）をチェックしてください。
また、Settingタブでは、管理者であれば、「カスタムサインアウトページを使用」してカスタムURLを設定できます。
SMS
ここには興味深い情報はありません。
エンドユーザーダッシュボード
ここには構成されたアプリケーションが表示されますが、後で別のセクションでそれらの詳細を見ることになります。
その他
興味深い設定ですが、セキュリティの観点からは特に興味深いものはありません。
アプリケーション
アプリケーション
ここでは、構成されたアプリケーションとその詳細を見つけることができます：誰がアクセス権を持っているか、どのように構成されているか（SAML、OPenID）、ログインするためのURL、Oktaとアプリケーション間のマッピングなど...
Sign Onタブには、アプリケーション設定を確認する際にユーザーがパスワードを表示できるようにする**Password reveal**というフィールドもあります。ユーザーパネルからアプリケーションの設定を確認するには、3つのドットをクリックしてください：
そして、アプリに関する詳細（パスワード表示機能が有効かどうかなど）をさらに見ることができます：
アイデンティティガバナンス
アクセス認証
アクセス認証を使用して、ユーザーのリソースへのアクセスを定期的にレビューし、必要に応じてアクセスを自動的に承認または取り消す監査キャンペーンを作成できます。
私はそれを使用したことはありませんが、防御の観点からは素晴らしい機能だと思います。
セキュリティ
一般
セキュリティ通知メール：すべてが有効になっている必要があります。
CAPTCHA統合：少なくとも不可視のreCaptchaを設定することが推奨されています。
組織セキュリティ：すべてを有効にでき、アクティベーションメールの有効期間は長くないほうがよい（7日でOK）。
ユーザー列挙防止：両方を有効にする必要があります。
ユーザー列挙防止は、次の条件のいずれかが許可されている場合には効果がありません（詳細はユーザー管理を参照）：
セルフサービス登録
メール認証付きのJITフロー
Okta ThreatInsight設定：脅威レベルに基づいてセキュリティを記録および強制する
HealthInsight
ここでは、正しくおよび危険な設定を見つけることができます。
認証アプリ
ユーザーが使用できるすべての認証方法をここで見つけることができます：パスワード、電話、メール、コード、WebAuthn... パスワード認証アプリをクリックすると、パスワードポリシーを確認できます。それが強力であることを確認してください。
登録タブでは、必須またはオプションのものを確認できます：
Phoneを無効にすることをお勧めします。最も強力なものはおそらく、パスワード、メール、WebAuthnの組み合わせです。
認証ポリシー
各アプリには認証ポリシーがあります。認証ポリシーは、アプリにサインインしようとするユーザーが特定の条件を満たしているかどうかを検証し、それらの条件に基づいてファクター要件を強制します。
ここでは、各アプリケーションにアクセスするための要件を見つけることができます。各アプリケーションに対して少なくともパスワードと別の方法を要求することが推奨されます。しかし、攻撃者としてより弱いものを見つけた場合、それを攻撃できるかもしれません。
グローバルセッションポリシー
ここでは、異なるグループに割り当てられたセッションポリシーを見つけることができます。例えば：
MFAの要求、セッションの有効期限を数時間に制限すること、ブラウザ拡張機能間でセッションクッキーを永続化しないこと、および場所とIdentity Providerを制限することが推奨されています（可能であれば）。例えば、すべてのユーザーが特定の国からログインする必要がある場合、この場所のみを許可することができます。
Identity Providers
Identity Providers（IdPs）はユーザーアカウントを管理するサービスです。OktaにIdPsを追加すると、エンドユーザーがソーシャルアカウントやスマートカードで最初に認証してカスタムアプリケーションに自己登録できるようになります。
Identity Providersページでは、ソーシャルログイン（IdPs）を追加し、受信SAMLを追加することでOktaをサービスプロバイダー（SP）として構成できます。IdPsを追加した後、ユーザーの場所、デバイス、またはメールドメインなどのコンテキストに基づいてユーザーをIdPに誘導するためのルーティングルールを設定できます。
攻撃者と防御者の観点から、構成されたIdentity Providerが信頼できるかどうかを確認し、攻撃者がそれを侵害するとOkta環境にアクセスできる可能性があることを確認してください。
委任認証
委任認証を使用すると、ユーザーは組織のActive Directory（AD）またはLDAPサーバーの資格情報を入力してOktaにサインインできます。
再度、この設定を再確認してください。組織のADを侵害する攻撃者は、この設定のおかげでOktaにピボットできる可能性があります。
ネットワーク
ネットワークゾーンは、アクセスを許可または制限するために使用できる構成可能な境界であり、アクセスを要求しているIPアドレスに基づいて組織内のコンピューターやデバイスへのアクセスを制御できます。ネットワークゾーンを定義するには、1つ以上の個々のIPアドレス、IPアドレスの範囲、または地理的位置を指定します。
1つ以上のネットワークゾーンを定義した後、グローバルセッションポリシー、認証ポリシー、VPN通知、およびルーティングルールでそれらを使用できます。
攻撃者の観点からは、許可されているIdPsを知ることが興味深いです（およびどのIPが他のIPよりも特権があるかを確認します）。ユーザーが特定のIPアドレスまたは地域からアクセスする必要がある場合は、この機能が適切に使用されているかどうかを確認してください。
デバイス統合
エンドポイント管理：エンドポイント管理は、認証ポリシーに適用できる条件であり、管理されたデバイスがアプリケーションにアクセスできることを確認します。
これを使用されていない。TODO
通知サービス：これを使用されていない。TODO
API
このページでOkta APIトークンを作成し、作成されたトークンの権限、有効期限、およびOrigin URLsを確認できます。APIトークンは、トークンを作成したユーザーの権限で生成され、トークンを作成したユーザーがアクティブである場合にのみ有効です。
Trusted Originsは、Okta APIを介してOkta組織にアクセスするために制御し信頼できるウェブサイトにアクセス権を付与します。
多くのAPIトークンが存在しないようにする必要があります。攻撃者はこれらにアクセスし、使用しようとする可能性があるためです。
ワークフロー
オートメーション
オートメーションを使用すると、エンドユーザーのライフサイクル中に発生する一連のトリガー条件に基づいて実行される自動アクションを作成できます。
たとえば、「Oktaでのユーザーの非アクティブ化」や「Oktaでのユーザーのパスワード有効期限切れ」といった条件があり、アクションは「ユーザーにメールを送信」または「Oktaでのユーザーライフサイクル状態を変更」などが考えられます。
レポート
レポート
ログをダウンロードします。これらは現在のアカウントのメールアドレスに送信されます。
システムログ
ここでは、ユーザーによって実行されたアクションのログを詳細に確認できます。OktaでのログインやOktaを介したアプリケーションへのログインなどが含まれます。
インポートモニタリング
Oktaでアクセスされた他のプラットフォームからログをインポートできます。
レート制限
達成されたAPIレート制限を確認します。
設定
アカウント
Okta環境に関する一般的な情報をここで見つけることができます。会社名、住所、請求連絡先のメールアドレス、技術連絡先のメールアドレス、またOktaの更新を受け取るべき担当者などが含まれます。
ダウンロード
ここでは、Oktaエージェントをダウンロードして、Oktaを他のテクノロジーと同期させることができます。
最終更新
