SCW 아이콘
영웅 배경, 구분선 없음
블로그

コーダーズ・コンカー・コンカー・セキュリティ:シェア&ラーニング・シリーズ-アクセス制御の破損

ヤープ・キャラン・シン
게시일 : 2019년 5월 9일
마지막 업데이트: 2026년 3월 10일

ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。

壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。

壊れたアクセス制御を理解する

アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。

会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。

これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。

アクセス制御の破れが危険な理由

次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。

システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。

顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか?URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。

壊れたアクセス制御を倒す

役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。

これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。

2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。

また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。

デリケートな機能を保護

アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。

攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。

機能レベルのアクセス権限を使い果たしているとお考えですか?壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]

리소스 표시
리소스 표시

ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。

더 관심이 있으신가요?

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

더 알아보세요

Secure Code Warrior는 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 구축하는 데 도움을 드립니다. 애플리케이션 보안 관리자, 개발자, CISO 또는 보안 담당자이든, 안전하지 않은 코드와 관련된 위험을 줄이는 데 도움을 드립니다.

데모 예약
공유:
링크드인 브랜드사회적x 로고
저자
ヤープ・キャラン・シン
게시일: 2019년 5월 9일

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

공유:
링크드인 브랜드사회적x 로고

ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。

壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。

壊れたアクセス制御を理解する

アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。

会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。

これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。

アクセス制御の破れが危険な理由

次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。

システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。

顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか?URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。

壊れたアクセス制御を倒す

役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。

これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。

2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。

また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。

デリケートな機能を保護

アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。

攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。

機能レベルのアクセス権限を使い果たしているとお考えですか?壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]

리소스 표시
리소스 표시

보고서를 다운로드하려면 아래 양식을 작성해 주세요.

당사 제품 및/또는 관련 보안 코딩 주제에 관한 정보를 발송할 수 있도록 허락해 주십시오. 당사는 고객의 개인정보를 항상 세심한 주의를 기울여 처리하며, 마케팅 목적으로 타사에 판매하지 않습니다.

발신
scw 성공 아이콘
scw 오류 아이콘
양식을 제출하려면 '분석' 쿠키를 활성화해 주세요. 설정이 완료되면 다시 비활성화해도 됩니다.

ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。

壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。

壊れたアクセス制御を理解する

アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。

会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。

これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。

アクセス制御の破れが危険な理由

次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。

システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。

顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか?URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。

壊れたアクセス制御を倒す

役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。

これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。

2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。

また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。

デリケートな機能を保護

アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。

攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。

機能レベルのアクセス権限を使い果たしているとお考えですか?壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]

온라인 세미나 보기
시작하자
더 알아보세요

아래 링크를 클릭하여 이 자료의 PDF를 다운로드하십시오.

Secure Code Warrior는 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 구축하는 데 도움을 드립니다. 애플리케이션 보안 관리자, 개발자, CISO 또는 보안 담당자이든, 안전하지 않은 코드와 관련된 위험을 줄이는 데 도움을 드립니다.

보고서 표시데모 예약
리소스 표시
공유:
링크드인 브랜드사회적x 로고
더 관심이 있으신가요?

공유:
링크드인 브랜드사회적x 로고
저자
ヤープ・キャラン・シン
게시일: 2019년 5월 9일

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

공유:
링크드인 브랜드사회적x 로고

ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。

壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。

壊れたアクセス制御を理解する

アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。

会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。

これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。

アクセス制御の破れが危険な理由

次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。

システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。

顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか?URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。

壊れたアクセス制御を倒す

役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。

これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。

2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。

また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。

デリケートな機能を保護

アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。

攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。

機能レベルのアクセス権限を使い果たしているとお考えですか?壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]

목차

PDF 다운로드
리소스 표시
더 관심이 있으신가요?

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

더 알아보세요

Secure Code Warrior는 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 구축하는 데 도움을 드립니다. 애플리케이션 보안 관리자, 개발자, CISO 또는 보안 담당자이든, 안전하지 않은 코드와 관련된 위험을 줄이는 데 도움을 드립니다.

데모 예약[다운로드]
공유:
링크드인 브랜드사회적x 로고
리소스 허브

시작하기 위한 리소스

기타 게시물
리소스 허브

시작하기 위한 리소스

기타 게시물