شركة Keeper صارمة بشأن أمان بيانات الاعتماد وحماية البيانات

تطبّق Keeper مستوى أمان عالميًا باستخدام التشفير الشامل والبنية القائمة على أسلوب صفر المعرفة ومبدأ انعدام الثقة لحماية معلوماتك ومنع وصول مجرمي الإنترنت إلى بياناتك.

لحمة سريعة عن أعلى مستوى أمان في المجال من Keeper

أقوى تشفير شامل

يحمي Keeper كلمات مرورك وأسرارك ومعلوماتك الشخصية بواسطة تشفير AES 256-bit وتشفير منحنى القطع الناقص (ECC)، وهذا الأمر مقبول على اعتباره التشفير الأقوى في مجال أمن الإنترنت.

يُعد Keeper موفر أمن قائم على أسلوب صفر المعرفة. وأسلوب صفر المعرفة هو بنية نظام تضمن أعلى مستويات الأمن والخصوصية. ويتم تشفير البيانات وفك تشفيرها دائماً محلياً على جهاز المستخدم.

برنامج مكافأة اكتشاف نقاط الضعف والخلل

يلتزم Keeper بحماية خصوصية عملائنا وبياناتهم الشخصية. حيث تتلخص مهمتنا في بناء تطبيقات الأمن الأكثر أماناً وابتكاراً في العالم، ونعتقد أن تقارير الأخطاء الصادرة من المجتمع العالمي للباحثين في مجال الأمن هي عنصر قيم لضمان أمن منتجات وخدمات Keeper. ولهذه الأسباب تشاركنا مع Bugcrowd لإدارة برنامج الإفصاح عن نقاط ضعفنا (VDP) وبرنامج مكافأة اكتشاف الأخطاء.

معتمد وفقاً لمعيار FIPS 140

Keeper معتمد من برنامج التحقق من نموذج التشفير NIST (CMVP) لاستيفائه لمعيار FIPS 140.

اختبار الاختراق

يتشارك Keeper مع خبراء خارجيين مثل مجموعة NCC، وCyberTest، وباحثي أمن مستقلين لإجراء اختبار الاختراق بشكل ربع سنوي على كل الحلول والأنظمة.

خزينة سحابية آمنة وموثوقة

يستخدم Keeper خدمات الويب من أمازون في عدة مناطق من بينها الولايات المتحدة وسحابة حكومة الولايات المتحدة والاتحاد الأوروبي وأستراليا وكندا واليابان – لاستضافة منصة وبينة Keeper وتشغيلهما، مما يوفر للعملاء التخزين السحابي المتاح الأكثر أماناً. حيث يتم عزل البيانات بالكامل في منطقة خدمات أمازون ويب المفضلة للعملاء أثناء النقل والثبات.

إتاحة عالية

يتم استضافة بنية Keeper العالمية في عدة مراكز بيانات تتمتع بإتاحة عالية على خدمات أمازون ويب. ومراكز البيانات هذه موزعة عبر عدة مناطق لخدمات أمازون ويب لضمان إتاحة الخدمة في حالة حدوث عطل إقليمي في الإنترنت.

مصادقة متعددة العوامل

يدعم Keeper المصادقة متعددة العوامل (MFA)، ومصادقة تسجيل الدخول الأحادي، وسياسات الوصول المشروط، ومفاتيح أمن أجهزة WebAuthn، ومفاتيح المرور، وتسجيل الدخول بالمقاييس الحيوية (مثل بصمة الوجه، وبصمة الإصبع وWindows Hello)، وKeeper DNA® الذي يستخدم أجهزة الساعة الذكية لتأكيد الهوية.

Zero-knowledge encryption

تشفر بيانات المستخدم ويفك تشفيرها على مستوى الجهاز ومستوى السجل، ولا يتم مطلقاً على السحابة أو على خوادم Keeper. حيث يحد التشفير على مستوى السجل من "دائرة" المعلومات المخزنة في خزائن المستخدم ويدعم العديد من ميزات الحد الأدنى من الامتياز في المنصة مثل مشاركة السجل.

نظرة عامة

Keeper Security, Inc. لديها شغف حيال حماية معلومات عملائها بواسطة برنامج أمن Keeper للهاتف الجوال ولجهاز سطح المكتب. يثق ملايين المستخدمين والشركات في Keeper لتأمين كلمات مرورهم ومعلوماتهم الخاصة والوصول إليها.

يتم تحسين برنامج Keeper وتحديثه بشكل مستمر لإمداد عملائنا بأحدث تكنولوجيا وحماية. وتوفر هذه الصفحة نظرة عامة عن بنية أمن Keeper ووسائل التشفير وبيئة الاستضافة للإصدار المنشور حالياُ. ويحتوي هذا المستند على نظرة عامة عن لتفاصيل التقنية المتعلقة بوسائل التشفير والأمن لدينا.

سياسة الخصوصية وشروط الاستخدام الخاصين بنا متاحة على موقع الويب الخاص بنا عبر الروابط التالية:

منصة قائمة على مبدأ انعدام الثقة

يستخدم Keeper بنية قائمة على مبدأ انعدام الثقة، وهو الأمر الذي من شأنه أن يضمن وجوب التحقق من كل مستخدم ومصادقته قبل أن يتمكن من الوصول إلى موقع ويب أو تطبيق أو نظام.

توفر إدارة كلمات المرور للمؤسسات من Keeper (EPM) رؤية وتحكم كاملين للشركات في ممارسات كلمات مرور موظفيها، وتمكن مسؤولي تكنولوجيا المعلومات من مراقبة استخدام كلمات المرور وإنفاذ أفضل ممارسات الأمن.

يوفر Keeper Secrets Manager= (KSM) منصة لفرق الهندسة لإدارة كل بيانات الاعتماد، بما في ذلك أسرار البنية التحتية، ومفاتيح SSH، ومفاتيح واجهة برمجة التطبيقات، واعتمادات مع حزم تطوير البرمجيات (SDK)، وتكامل CI/CD.

يُعد Keeper Connection Manager (KCM) بوابة جهاز سطح مكتب عن بُعد تمد فرق DevOps وتكنولوجيا المعلومات بوصول للشبكة قائم على مبدأ انعدام الثقة (ZTNA) دون عناء إلى RDP، وSSH، وقواعد البيانات، وتطبيقات الويب الداخلية، ونقاط نهاية كوبيرنيتيس عبر متصفح ويب، من دون الحاجة إلى وكيل.

كيف يدعم Keeper منصة قائمة على مبدأ انعدام الثقة
نموذج التشفير والأمن من Keeper

نظرة معمّقة على مستوى الأمان الأفضل في المجال من Keeper

تشفير بيانات الخزينة

يوفر Keeper نموذج تشفير متعدد الطبقات قائماً على الحد الأدنى من الامتياز. ويتم توليد مفاتيح على مستوى السجل ومفاتيح على مستوى المجلد بتشفير 256-bit AES على جهاز العميل، وهو ما يشفر كل سجل مخزن في الخزينة. ويتم تشفير سجلات الخزينة مع كل محتوياتها، بما في ذلك بيانات تسجيل الدخول ومرفقات الملفات ورموز كلمة المرور لمرة واحدة المستندة إلى الوقت ومعلومات الدفع وعناوين URL والحقول المخصصة.

يتم توليد مفاتيح التشفير محلياً على الجهاز للحفاظ على أسلوب صفر المعرفة ودعم الميزات المتقدمة مثل مشاركة السجلات والمجلدات. وأسلوب صفر المعرفة يعني أن لكل مستخدم تحكم كامل في تشفير كل معلوماته الشخصية وفك تشفيرها داخل خزينة Keeper، ولا يمكن لأي شخص آخر الوصول إلى معلوماته المخزنة، ولا حتى موظفي Keeper.

يتم تشفير مفاتيح السجلات ومفاتيح المجلدات بواسطة مفتاح بيانات 256-bit AES فريد لكل مستخدم ويتم توليده على جهاز المستخدم.

يولد على جهاز المستخدم مفتاح عميل 256-bit AES آخر لتشفير ذاكرة تشفير مؤقت محلية من دون إنترنت (إذا كان مسؤول مؤسستك يسمح بالوصول من دون إنترنت). وأخيراً، يتم تشفير مفتاح بيانات 256-bit AES بمفتاح آخر على النحو الموضح في القسم التالي.

طرق تشفير الخزينة

يقوم Keeper بتشفير البيانات بطرق مختلفة استناداً إلى الكيفية التي يقوم بها المستخدمون بتسجيل الدخول. فيما يتعلق بالمستهلكين وأعضاء خطة العائلة يتم استخدام كلمة مرور رئيسية ومصادقة بالمقاييس الحيوية. وفيما يتعلق بمستخدمي الشركات والمؤسسات الذين يقومون بتسجيل الدخول بواسطة تسجيل الدخول الأحادي، يستخدم Keeper تشفير منحنى القطع الناقص لتجربة آمنة ومن دون كلمات مرور.

فيما يتعلق بالمستخدمين الذين يستخدمون كلمة مرور رئيسية لتسجيل الدخول: يتم اشتقاق المفتاح المستخدم لفك تشفير مفتاح البيانات وتشفيره من كلمة المرور الرئيسية للمستخدم، باستخدام وظيفة تنويع المفاتيح القائمة على كلمة المرور (PBKDF2)، مع 1,000,000 تكرار. فبعد أن يكتب المستخدم كلمة مروره الرئيسية، يتم اشتقاق المفتاح محلياً ثم يتم الكشف عن مفتاح البيانات. ويتم فك تشفير مفتاح البيانات ويستخدم للكشف عن سجلات ومفاتيح المجلدات الفردية. ويؤدي فك تشفير كل مفتاح إلى تخزين محتويات السجل محلياً على جهاز المستخدم.

تشفير نموذج تسجيل الدخول بكلمة المرور الرئيسية من Keeper

فيما يتعلق بالمستخدمين الذين يسجلون الدخول بتقنية تسجيل الدخول الأحادي أو من دون كلمة مرور: يتم استخدام تشفير منحنى القطع الناقص لتشفير البيانات وفك تشفيرها على مستوى الجهاز. ويتم استخدام مفتاح ECC-256 (secp256r1) محلي خاص لفك تشفير مفتاح البيانات. وبعد فك تشفير مفتاح البيانات، يتم استخدامه للكشف عن مفاتيح السجلات والمجلدات الفردية. ثم يقوم مفتاح السجل بعدها بفك تشفير كل من محتويات السجل المخزن. ويتم نقل مفتاح البيانات المشفر بين أجهزة المستخدم عبر نظام إرسال أو خدمة تبادل مفاتيح، ويطلق عليها اسم اعتماد الجهاز (Device Approval). للحفاظ على أسلوب صفر المعرفة، وتتم إدارة موافقة الجهاز محلياً من قبل المستخدم النهائي.

سحابة SSO Connect – نموذج التشفير متعدد الطبقات

نموذج تشفير تسجيل الدخول الأحادي

تدفق الجهاز الأول (إلحاق مستخدم جديد)

  1. يتم توليد مفتاح البيانات وزوج مفاتيح المشاركة وزوج مفاتيح منحنى القطع الناقص الخاص/العام للجهاز
  2. يتم تشفير مفتاح البيانات بواسطة المفتاح العام لمنحنى القطع الناقص للجهاز ويخزن في السحابة (DEDK)
  3. يقوم المستخدم بتسجيل الدخول باستخدام موفر الهوية الخاص به
  4. بعد تسجيل دخول موفر الهوية، يتم التحقق من تأكيد SAML المسجل بواسطة Keeper
  5. تم إنشاء الخزينة وإلحاق المستخدم

تدفق الجهاز الحالي

  1. يقوم المستخدم بتسجيل الدخول باستخدام موفر الهوية الخاص به
  2. بعد تسجيل دخول موفر الهوية، يتم التحقق من تأكيد SAML المسجل بواسطة Keeper
  3. يقدم Keeper مفتاح البيانات المشفر على الجهاز (DEDK) للمستخدم
  4. يتم فك تشفير مفتاح البيانات بواسطة مفتاح منحنى القطع الناقص الخاص بالجهاز
  5. يقوم مفتاح البيانات بفك تشفير مفاتيح المجلد ومفاتيح السجل
  6. تقوم مفاتيح السجل بفك تشفير محتويات السجل

تدفق الأجهزة الجديدة أو غير المعروفة

  1. يتم توليد زوج مفاتيح منحنى قطع ناقص خاص/عام على كل جهاز جديد
  2. يقوم المستخدم بتسجيل الدخول باستخدام موفر الهوية الخاص به
  3. بعد تسجيل دخول موفر الهوية، يتم التحقق من تأكيد SAML المسجل بواسطة Keeper
  4. تم "اعتماد" الجهاز عبر Keeper Push، أو باعتماد المسؤول أو خدمة Keeper Automator (*راجع اعتماد الجهاز أدناه)
  5. خلال عملية الاعتماد يتم تشفير مفتاح البيانات بواسطة المفتاح العام للجهاز الجديد
  6. يتم إرسال مفتاح البيانات المشفر على الجهاز (DEDK) إلى المستخدم

الموافقة على الجهاز

  • يُعد اعتماد الجهاز آلية لتأمين توصيل مفتاح بيانات المستخدم لجهازه الجديد مع الحفاظ على أسلوب صفر المعرفة
  • يمكن للمستخدم اعتماد جهازه عبر تشفير مفتاح البيانات بواسطة المفتاح العام للجهاز الجديد
  • يمكن للمسؤول اعتماد الجهاز من وحدة تحكم المسؤول، أو Commander، أو خدمة Keeper Automator
  • يقوم المسؤول بفك تشفير مفتاح بيانات المستخدم وإعادة تشفير مفتاح البيانات بواسطة المفتاح العام للجهاز الجديد
  • يمكن أن تقوم خدمة Keeper Automator باعتمادات مؤتمتة للأجهزة على البنية التحتية للعميل
  • يتحقق Keeper Automator من توقيع SAML، ويكشف عن مفاتيح البيانات ويشفر مفتاح البيانات بواسطة المفتاح العام للجهاز الجديد

اقرأ المزيد حول خدمة Keeper Automator.

الأمان على مستوى الجهاز لـ SSO Connect Cloud

فيما يتعلق بعملاء سحابة SSO Connect، يتم توليد مفتاح منحنى القطع الناقص الخاص ويخزن محلياً على كل جهاز. وفي متصفحات الويب الحديثة وتطبيق سطح المكتب من Keeper القائم على إلكترون، تخزن خزينة Keeper مفتاح منحنى القطع الناقص الخاص المحلي للجهاز (“DPRIV”) على أنه CryptoKey غير قابل للتصدير. وعلى الأجهزة التي تعمل بنظام تشغيل iOS وmacOS، يتم تخزين المفتاح في سلسلة المفاتيح الخاصة بالجهاز. وعلى الأجهزة التي تعمل بنظام تشغيل أندرويد يتم تشفير المفتاح بواسطة Android Keystore، باستخدام التفضيلات المشتركة المشفرة. ويستخدم Keeper آليات التخزين الآمن على كل نظام تشغيل، حيثما كان ذلك متاحاً.

لا يُستخدَم المفتاح الخاص للجهاز مباشرة لتشفير بيانات الخزينة أو فك تشفيرها، فعند نجاح المصادقة من جانب موفر الهوية، يتم استخدام مفتاح منفصل (غير مخزن) لفك تشفير بيانات الخزينة. وبناء عليه، لا يمكن لاستخراج المفتاح الخاص المحلي للجهاز من دون إنترنت أن يفك تشفير خزينة المستخدم.

تشفير البيانات المخزنة (في حالة الثبات)

يستخدم Keeper خدمة أمازون ويب لاستضافة منصة وبنية Keeper. حيث تتمركز مراكز بيانات خدمة أمازون ويب الخاصة بنا في عدة مواقع جغرافية، ويستطيع عملائنا استضافة مستأجر Keeper الخاص بهم في أي منطقة أساسية مفضلة. ويضمن هذا الأمر أن يتم عزل بيانات العميل ووصوله للمنصة إلى هذه المنطقة المحددة.

يتم تشفير بيانات الخزينة في حالة السكون على جهاز المستخدم بشكل محلي باستخدام AES-256 GCM ويتم تشفير البيانات المشفرة المنقولة بواسطة TLS 1.3 باستخدام طبقة تشفير إضافية في البيانات الأساسية. ويتم عزل بيانات العميل عبر استخدام التشفير على مستوى السجل.

يلتزم نموذج التشفير من Keeper بالبنية التالية:

  • يتم تشفير كل الخزائن بواسطة مفتاح 256-bit AES يولد من جانب العميل في نمط GCM.
  • يتم تغليف كل المفاتيح على مستوى السجلات في المجلد المشترك بواسطة مفتاح مجلد مشترك 256-bit AES.
  • يتم تشفير مفاتيح السجل والمجلد لخزينة المستخدمين بواسطة مفتاح 256-bit AES آخر يطلق عليه اسم مفتاح البيانات.
  • فيما يتعلق بـ Keeper Secrets Manager (KSM)، يتم تشفير مفاتيح السجل والمجلد الخاصين بالمستخدم بواسطة مفتاح تطبيق 256-bit AES.
  • فيما يتعلق بالمستخدمين الذين يقومون بتسجيل الدخول بواسطة كلمة المرور الرئيسية، يتم اشتقاق المفاتيح المستخدمة لتشفير البيانات وفك تشفيرها من كلمة المرور الرئيسية.
  • يستخدم تسجيل الدخول بواسطة تقنية تسجيل الدخول الأحادي أو من دون كلمة مرور تشفير منحنى القطع الناقص لتشفير البيانات على الجهاز أو فك تشفيرها.
  • يتم إرسال كل البيانات الأساسية المشفرة إلى خوادم Keeper وتغلف بمفتاح نقل 256-bit AES مع TLS، للحماية من هجمات الوسيط (MITM). ويتم توليد المفتاح عند العميل وينقل بواسطة تشفير نظام التشفير المتكامل لمنحنى القطع الناقص (ECIES) عبر مفتاح منحنى القطع الناقص العام للخادم.
  • تستخدم المشاركة الآمنة للأسرار بين المستخدمين توزيع مفتاح تشفير منحنى القطع الناقص.
رسم توضيحي لتشفير السجلات

إدارة إصدارات السجلات

يحتفظ Keeper بسجل الإصدار المشفر الكامل لكل سجل مخزن في خزينة المستخدم، مما يمنح الثقة أنه لن يتم فقدان أي بيانات مهمة مطلقاً. يستطيع المستخدمون تجربة تاريخ السجل والقيام بعملية استعادة لأي سجل خزينة فردية من تطبيق عميل Keeper. إذا تم تغيير كلمة مرور أو ملف مخزن في Keeper أو حذفهم، يكون هناك دائماً لدى المستخدمين القدرة على الاستعادة في وقت ما.

Keeper Business

يتم إمداد العملاء الذين يقومون بشراء Keeper Business بطبقة تحكم إضافية في مستخدميهم وأجهزتهم. حيث يتم إمداد مسؤولي Keeper بوصول لوحدة تحكم إدارية قائمة على السحابة مما يسمح بتحكم كامل في إلحاق المستخدمين، وإلغاء إلحاقهم، والأذونات القائمة على الأدوار، والإدارة المفوضة، والفرق، وتكامل Active Directory/LDAP، والمصادقة الثنائية، , وتسجيل الدخول الأحادي، وسياسات إنفاذ الأمن. ويمكن تخصيص سياسات الإنفاذ القائمة على الأدوار من Keeper وتوسيعها للمؤسسات من أي حجم.

تشفير فائق للبيانات المخزنة (في حالة الثبات)

علاوة على تخزين النص المشفر المشفر على الجهاز في البنية التحتية لخدمة أمازون ويب، كما يقوم Keeper بتشفير فائق مع نماذج أمن الأجهزة المتعددة المناطق (HSM) باستخدام مفاتيح غير قابلة للتصدير.

تشفير النسخ الاحتياطية وحمايتها

يحافظ برنامج Keeper على سجل مراجعة كاملة لكل سجل، على مستوى المنتج/المستخدم. وبناء عليه إذا طلب مستخدم استعادة، يمكنه عرض الإصدارات السابقة وإعادتها من سجلات Keeper المخزنة في أي وقت ومن دون حدود عبر واجهة المستخدم.

يتم تكرار قواعد البيانات وعناصر الملفات المشفرة من Keeper وتنسخ احتياطياً في عدة مناطق جغرافية لأغراض الاستعادة في حالات الكوارث، على مستوى النظام. ويتم تشفير كل النسخ الاحتياطية بتشفير AES-256 فضلاً عن التشفير الفائق للتشفير النصي المولد من الجهاز.

فيما يتعلق بالعملاء الذين يحتاجون لمساعدة في الاستعادة (على سبيل المثال، بسبب حذف عميل لخزينة أو مجلد مشترك عن طريق الخطأ)، يستطيع فريق دعم Keeper المساعدة في استعادة من أي وقت (وصولاً للدقيقة) خلال 30 يوماً. ويمكن أن يساعد دعم Keeper في أي عملية استعادة مثل استعادة مستخدم أو استعادة خزينة أو استعادة مؤسسة بالكامل.

استعادة الحساب

تمكن عبارة الاستعادة المكونة من 24 كلمة عملاء Keeper من استعادة الوصول إلى خزائن Keeper الخاصة بهم إذا ما فقدوا كلمات مرورهم الرئيسية أو نسوها.

طبق Keeper عبارات الاستعادة باستخدام نفس قائمة كلمات BIP39 المستخدمة لحماية محافظ التشفير. وقائمة الكلمات المستخدمة في BIP39 هي مجموعة مكونة من 2,048 كلمة تستخدم لتوليد مفتاح تشفير بواسطة 256 bits من الاعتلاج. وتستخدم طريقة الاستعادة هذه بشكل شائع في محافظ البيتكوين والعملات الرقيمة الشائعة. ويتم اختيار كل كلمة في قائمة BIP39 بعناية لتحسين الرؤية وجعل عملية الاستعادة أقل عرضة للخطأ. ويجب على المستخدمين كتابة عبارة الاستعادة وتخزينها في مكان آمن مثل خزينة.

تولد عبارة الاستعادة مفتاح 256-bit AES يقوم بتشفير نسخة من مفتاح بيانات المستخدم. سيحتاج المستخدمون إلى عبارة الاستعادة مع تحقق من البريد إلكتروني ومصادقة ثنائية (2FA)، لاستعادة الحساب وإعادة تعيين كلمة المرور الرئيسية.

يمكن لمسؤولي المؤسسات إيقاف استعادة الحساب على مستوى سياسة إنفاذ الأدوار.

ضبط عبارة الاستعادة

مفاتيح تشفير المؤسسة

يستطيع عملاء Keeper Enterprise وKeeper Business إدارة العديد من القدرات المختلفة الخاصة بمنصة Keeper مثل سياسات الوصول القائم على الأدوار، والتزويد والمصادقة والإدارة.

تتم حماية وظائف المسؤول بواسطة منصة Keeper عبر كل من التشفير والمصادقة، حيث تضمن المصادقة أن يتمكن المستخدمين المعنيين فقط من القيام بوظائف محددة. ويضمن التشفير أن يتمكن المسؤولون المعينون من القيام بوظائف تتضمن بيانات الخزينة أو مفاتيح يتم التحكم بها من قبل المؤسسة بشكل مادي وتشفيري. وتتضمن بعض الأمثلة ما يلي:

  • منصة Keeper هي منصة إدارة مفاتيح فعلية، حيث يوجد لدى المستخدمين والمسؤولين تحكم كامل في مفاتيحهم الخاصة.
  • يتم استخدام أزواج مفاتيح التشفير العام والخاص في إنشاء الأجهزة، والمستخدمين والفرق.
  • تستخدم سياسات الأدوار للنقل الخزائن وتنفيذ عمليات اعتماد الأجهزة مفاتيح تشفير عامة وخاصة.
  • يتم استخدام أزواج مفاتيح منحنى القطع الناقص (EC) لمشاركة البيانات بين المستخدمين ومن المستخدمين الأفراد إلى المسؤول على مستوى المؤسسة.
  • يتم تشفير بيانات الاستخدام الحساسة مثل قوة كلمة مرور السجل بالمفاتيح العامة للمؤسسة والتي لا يستطيع أن يفك تشفيرها أي شخص سوى المسؤول.
  • يتم تشفير حقول عنوان السجل وعنوان URL ونوع السجل لكل سجل خزينة مستخدم في المؤسسة بواسطة المفتاح العام للمؤسسة ويمكن فك تشفيره من وحدة تحكم مسؤول Keeper، من خلال المسؤول المعني بامتيازات إعداد تقارير الامتثال.

التحقق من الجهاز

يجب أن يجتاز المستخدم خطوة اعتماد الجهاز والتحقق منه قبل أن يحاول تسجيل الدخول إلى الحساب. حيث يمنع التحقق من الجهاز تعداد الحسابات ويحمي من هجمات القوة الغاشمة.

يستطيع العملاء الذين يقومون بتسجيل الدخول بواسطة كلمة المرور الرئيسية القيام بالتحقق من الجهاز بعدة طرق تشمل ما يلي:

  • رسالة البريد الإلكتروني لرمز التحقق
  • إدخال رمز المصادقة الثنائية من برنامج لكلمات المرور الصالحة لمرة واحدة المستندة إلى الوقت أو رسالة نصية
  • استخدام Keeper Push لإرسال رسالة لجهاز معترف به

فيما يتعلق بالعملاء الذين يقومون بالمصادقة بواسطة سحابة SSO Connect من Keeper، يتم اعتماد الجهاز بواسطة مفتاح نقل، حيث يتم تسليم مفتاح البيانات المشفر الخاص بالمستخدم إلى الجهاز، والذي يقوم بفك التشفير محلياً باستخدام المفتاح الخاص لمنحنى القطع الناقص للمستخدم. وتتضمن طرق اعتماد الجهاز ما يلي:

  • Keeper Push (باستخدام دفع الإشعارات) لأجهزة المستخدم الحالية
  • اعتماد المسؤول عبر وحدة تحكم المسؤول من Keeper
  • اعتماد تلقائي عبر خدمة Keeper Automator
  • اعتماد مسؤول تلقائي عبر Commander CLI

اعرف المزيد حول اعتمادات الأجهزة.

خصوصية البيانات

Keeper متوافق مع لوائح القانون العام لحماية البيانات (GDPR) ويضمن كذلك التزام عملياتنا ومنتجاتنا بلوائح القانون العام لحماية البيانات (GDPR) بالنسبة إلى عملائنا في الاتحاد الأوروبي وفي العالم أجمع. We comply with the EU-U.S. Data Privacy Framework ("EU-U.S. DPF"), the UK Extension to the EU-U.S. DPF, the German Federal Data Protection Act (BDSG) and the Swiss-U.S. Data Privacy Framework ("Swiss-U.S. DPF") as set forth by the U.S. Department of Commerce.

راجع سياسة الخصوصية وفقاً للقانون العام لحماية البيانات (GDPR) من Keeper.

لا تتضمن أي من تطبيقات Keeper متعقبات أو مكتبات خارجية تجري عمليات تتبع. على سبيل المثال، يوفرهذا التقرير معلومات حول تطبيق Keeper لنظام تشغيل أندرويد ويعرض أنه لم يتم تثبيت أي متعقبات.

عزل البيانات

Keeper هي منصة برامج كخدمة مُدارة بالكامل وتستضيف بياناتها في عدة مراكز بيانات AWS معزولة جغرافيًا. يجوز للمؤسسات استضافة مستأجر Keeper الخاص بها في منطقتها الرئيسية المفضلة. يتم عزل بيانات العملاء والوصول إلى المنصة في تلك المنطقة المحددة.

المناطق المتاحة:

  • الولايات المتحدة (US)
  • سحابة حكومة الولايات المتحدة (US_GOV)
  • أوروبا (EU)
  • أستراليا (AU)
  • اليابان (JP)
  • كندا (CA)

التشفير أثناء الانتقال

خزينة Keeper محمية بواسطة واجهات برمجة التطبيقات، والتي تم التحقق منها عبر المصادقة على جهاز المستخدم.

  • يستعيد المستخدم رمز جلسة مميز بواسطة تسجيل الدخول الخاص به ويرسله مع كل استدعاء لواجهة برمجة تطبيقات.
  • يتم إدارة رمز الجلسة المميز والتحكم به من على خادم خلفي.
  • يتم تسجيل الدخول بواسطة كلمة المرور الرئيسية أو المقاييس الحيوية أو استئناف الجلسة أو مصادقة تسجيل الدخول الأحادي SAML 2.0.

عند استخدام كلمة مرور رئيسية، يشتق جهاز المستخدم مفتاح مصادقة 256-bit باستخدام PBKDF2-HMAC_SHA256 مع 1,000,000 تكرار وتشفير عشوائي. ويتم إنشاء تجزئة مصادقة عبر تجزئة مفتاح المصادقة باستخدام SHA-256. عند تسجيل الدخول، تتم مقارنة المصادقة المجزئة مع المصادقة المجزئة المخزنة في خزينة Keeper. وبعد أن يقوم المستخدم بتسجيل الدخول، يتم إنشاء رمز جلسة مميز على الخادم ويُرسل إلى المستخدم ليستخدمه الجهاز في مطالبات واجهة برمجة التطبيقات اللاحقة. وللسماح بالاستخدام المستمر لاتصالات العميل بالخادم، يجب أن تكون الجلسة مفعلة.

  • يستخدم Keeper تشفير 256-bit و128-bit TLS لتشفير 100% من البيانات المخزنة في تطبيق المستخدم وتخزين الملفات الآمن من Keeper.
  • ينشر Keeper اعتمادات TLS الموقعة باستخدام خوارزمية SHA2. حيث تُعد SHA2 خوارزمية التوقيع المتاحة الأكثر أماناً في الوقت الحالي من قبل سلطات الاعتماد التجاري. ويحمي استخدام Keeper لـ SHA2 من الاعتمادات المزورة التي قد يستخدمها المهاجم لانتحال صفة موقع ويب.

مصادقة السحابة

قام Keeper بإنشاء نموذج متقدم للمصادقة السحابية واتصالات لشبكة مع أعلى درجات الخصوصية والأمن والثقة والشفافية. وتتضمن بعض الميزات الرئيسية لنموذج المصادقة هذا ما يلي:

التكامل مع أي مقدم لـ SAML 2.0

يتكامل Keeper مع كل موفري الهوية المتسقين مع SAML 2.0، بما في ذلك Okta، وMicrosoft Entra ID (Azure)، وAD FS، وGoogle Workspace، وCentrify، وOneLogin، وPing Identity، وJumpCloud، وDuo، وAuth0، والكثير غيرهم.

توفر منتجاتنا نوعين مختلفين من أنواع تسجيل الدخول الأحادي سحابة SSO Connect وSSO Connect في المقر. ويوفر كلا التطبيقين بنية قائمة على أسلوب صفر المعرفة مع مصادقة سلسة للمستخدمين.

لا يتم نقل كلمات المرور الرئيسية للمستخدم أبدًا عبر طبقة الشبكة

بخلاف معظم خدمات SaaS، لا تغادر بيانات اعتماد تسجيل دخول المستخدمين الخاصة بـ Keeper أجهزتهم. فعندما يقوم المستخدمون بتسجيل الدخول إلى Keeper باستخدام كلمة مرور رئيسية، يتم استخدام PBKDF2 على الجهاز المحلي لاشتقاق مفتاح 256-bit AES لفك التشفير. علاوة على توليد مفتاح PBKDF2 على مستوى الجهاز ثم تجزئته بواسطة HMAC_SHA256 لإنشاء رمز مصادقة مميز. ولا يوجد لدى Keeper أي معرفة بمفتاح فك تشفير المستخدم.

لا يمكن اعتراض نقل البيانات بين جهاز العميل وKeeper Cloud أو فك تشفيرها

يتم تغليف كل البيانات الأساسية المشفرة المرسلة إلى خوادم Keeper بمفتاح نقل 256-bit AES وTLS لحمايتها من هجمات الوسيط (MITM). ويتم توليد مفتاح النقل على جهاز العميل وينقل إلى الخادم باستخدام تشفير ECIES عبر مفتاح منحنى القطع الناقص العام للخادم.

لا يمكن استخدام الأجهزة الجديدة لتسجيل الدخول إلى Hd حساب من دون خطوة تحقق

لا يمكن للمستخدمين استخدام أجهزة جديدة لتسجيل الدخول إلى حسابات Keeper الخاصة بهم من دون استخدام طريقة تحقق. حيث يدعم Keeper عدة أنواع من طرق التحقق، استناداً إلى نظام المصادقة.

يتم إجراء المصادقة متعددة العوامل بعد التحقق وقبل أن يدخل المستخدم كلمة مروره الرئيسية

إذا كان يوجد لدى المستخدم مصادقة متعددة العوامل مثبتة أو مفروضة، فيجب عليه أن يجتاز هذه الخطوة أولاً قبل إدخال كلمة مروره الرئيسية.

لا يمكن إدخال كلمة المرور الرئيسية حتى تنجح خطوة التحقق من الجهاز والمصادقة متعددة العوامل

إذا لم يتم تحديد أي طريقة تحقق، فلن يتمكن المستخدم من إدخال كلمة مروره الرئيسية. حيث تحمي المصادقة المتقدمة هذه من عدة طرق شائعة للهجمات، وتشمل هجمات القوة الغاشمة، ورش كلمات المرور، والتعداد، وهجمات الوسيط.

المصادقة متعددة العوامل

للحماية من الوصول غير المفوض إلى حساب العميل، توفر Keeper المصادقة متعددة العوامل (MFA)، وأحد نهج المصادقة الذي يتطلب عاملين أو أكثر من عوامل المصادقة، وتكون عامل معرفة و/أو عامل مملوك و/أو عامل موروث. اعرف المزيد حول ضبط المصادقة متعددة العوامل في Keeper.

يستخدم Keeper كلمة مرورك الرئيسية والجهاز الذي بحوزتك لتوفير طبقة أمان إضافية إذا ما تم اختراق كلمة مرورك الرئيسية أو جهازك. ويدعم Keeper مفاتيح الأجهزة FIDO2 WebAuthn والحلول القائمة على البرامج مثل كلمة المرور لمرة واحدة المستندة إلى الوقت أو الرسائل النصية القصيرة.

عند استخدام طريقة مصادقة متعددة العوامل/مصادقة ثنائية باستخدام كلمة المرور لمرة واحدة المستندة إلى الوقت، يولد Keeper مفتاح سر 10 بايت باستخدام مولد أرقام عشوائية بتشفير آمن. ويكون هذا الرمز صالحاً لحوالي دقيقة ولا يمكن إعادة استخدامه فور نجاح المصادقة. كما يدعم Keeper أي تطبيق لكلمات المرور لمرة واحدة المستندة إلى الوقت بما في ذلك Google Authenticator وMicrosoft Authenticator. كما يتكامل Keeper مباشرة مع خدمات المصادقة المتعددة العوامل الشائعة مثل Duo وRSA SecurID.

عند استخدام مصدقي المصادقة متعددة العوامل مثل Google Authenticator، أو Microsoft Authenticator أو تطبيقات لكلمات المرور لمرة واحدة المستندة إلى الوقت الأخرى على جهاز هاتفك الجوال، يولد خادم Keeper داخلياً رمز QR يتضمن مفتاحك السري. وفي كل مرة ينشط أحد المستخدمين المصادقة متعددة العوامل يتم توليد مفتاح جديد.

لتنشيط المصادقة متعددة العوامل، انتقل إلى شاشة الإعدادات بتطبيق الويب أو تطبيق سطح المكتب أو تطبيق نظام تشغيل iOS/Android من Keeper. كما يستطيع مسؤولو Keeper Business إنفاذ استخدام المصادقة متعددة العوامل وطرق المصادقة متعددة العوامل عبر وحدة تحكم المسؤول من Keeper.

يتم توفير دعم WebAuth المتسق مع FIDO2 عبر Keeper، من خلال مفتاح أمن قائم على الجهاز مثل YubiKey وGoogle Titan keys كعامل إضافي. كما يتم دعم مفاتيح المرور كعامل مصادقة ثنائية باستخدام الأجهزة المادية أو متصفحات الويب. وتوفر مفاتيح الأمن طريقة آمنة لإجراء المصادقة متعددة العوامل من دون الحاجة إلى أن يقوم المستخدم بإدخال الرموز يدوياَ.

Android Smart WatchAndroid Smart Watch Apple Smart WatchApple Smart Watch DUODUO EntrustEntrust Google AuthenticatorGoogle Authenticator Microsoft Authenticator Microsoft Authenticator RSA SecureIDRSA SecureID الرسائل النصية القصيرةالرسائل النصية القصيرة Titan Security KeyTitan Security Key TOTPTOTP YubicoYubico

Keeper Active Directory / LDAP Bridge

يتكامل Keeper Bridge مع خوادم Active Directory وLDAP لتزويد المستخدمين وإلحاقهم. ويتم في البداية تفويض اتصالات Keeper Bridge من قبل مسؤول لديه امتياز إدارة الجسر. ويتم توليد مفتاح نقل ومشاركته مع Keeper لكل الاتصالات اللاحقة. ويعمل مفتاح النقل بمثابة تفويض لكل العمليات التي تتم من خلال الجسر فيما عدا إنشاء الجسر. ويمكن إعادة توليد مفتاح النقل في أي وقت ويتم تدويره تلقائياً كل 30 يوماً.

ويعمل مفتاح النقل لأغراض النقل فقط، مما يعني أنه يمكن إعادة تهيئة أي مفتاح مخترق أو إلغاؤه من دون أي فقدان في البيانات أو الأذونات.

لا يستطيع Keeper Bridge منح امتيازات للدور أو للمستخدم. ويمكنه إضافة مستخدم لدور متميز، طالما لا يوجد حاجة لمفاتيح الإنفاذ. ولا يجوز أن يقوم Keeper Bridge بترقية نفسه أو مستخدم بما يتجاوز الشجرة التي يقوم بإدارتها. ولا تتاح كل العمليات لـ Bridge، على سبيل المثال يمكن أن يقوم Bridge بتعطيل مستخدم نشط، ولكن لا يمكنه حذف المستخدم. ويتعين على المسؤول اختيار إذا ما كان سيتم حذف المستخدم أم نقله.

Keeper Active Directory / LDAP Bridge

مصادقة تسجيل الدخول الأحادي بواسطة المصادقة متعددة العوامل

عندما يتم نشر Keeper باستخدام حل تسجيل دخول أحادي مثل Entra ID/‏Azure AD، أو Okta، أو Ping، أو Google Workspace أو أي مقدم هوية SAML 2.0 آخر، يكون بالإمكان إدارة المصادقة متعددة العوامل بالكامل أثناء عملية تسجيل الدخول بواسطة مقدم الهوية. كما تدعم Keeper سياسات الوصول المشروط الخاصة بـ Azure عبر كل أنواع الأجهزة والتطبيقات.

يمكن إنفاذ المصادقة متعددة العوامل على جانب موفر الهوية وجانب Keeper. على سبيل المثال فور نجاح مستخدم في خطوة المصادقة متعددة العوامل مع موفر الهوية، يمكن أن يفرض عليه علاوة على ذلك أن ينجح في خطوة مصادقة متعددة العوامل ثانية في واجهة Keeper. ويمكن فرض هذه السياسة من قبل مسؤول Keeper.

Amazon Web ServicesAmazon Web Services CASCAS CentrifyCentrify DUODUO F5F5 Google WorkplaceGoogle Workplace IBM SecurityIBM Security JumpCloudJumpCloud Microsoft ADFSMicrosoft ADFS OneloginOnelogin Okta Okta Ping IdentityPing Identity

مصادقة SAML 2.0 باستخدام SSO Connect Cloud

تمكن سحابة Keeper SSO Connect عملاء المؤسسات من التكامل تماماً مع Keeper بواسطة أي موفر هوية يمتثل إلى SAML 2.0 ونشر الخزائن المشفرة إلى مستخدميهم.

SAML implementation with Keeper allows a user to authenticate through their SSO IdP and then decrypt their vault ciphertext on their device. Every user device has an individual Elliptic Curve (EC) key pair and encrypted data key. In addition, each user has their own 256-bit AES data key. When signing in to Keeper using a new device, the user must utilize existing devices to perform an approval or, alternatively, an admin with privileges can approve their device.

This capability is essential so a user can decrypt their vault locally, on their device, without the requirement of a master password or password key derivation. Zero knowledge is maintained because the cloud cannot decrypt the user's data key. Instead, the device-encrypted data key (DEDK) is provided to the user upon successful authentication of the IdP (e.g., Okta, Azure, Google Workspace, AD FS, Ping, Duo, Jumpcloud, etc.). The data key for the user is decrypted locally on the device with the elliptic curve device private key. Keeper holds US Utility Patents on this technology, which has been in production since 2015.

تُعدّ Keeper Automator خدمة اختيارية تقوم بإجراء عمليات موافقة فورية على الفرق، وموافقة على الأجهزة، كما تعيّن فِرقًا للمستخدمين عند نجاحهم في تسجيل الدخول من مقدم هوية تسجيل الدخول الأحادي.

بمجرد تشغيل Automator، يمكن للمستخدمين الوصول إلى Keeper بسلاسة على الأجهزة الجديدة (غير الموافق عليها مسبقًا) بعد نجاح المصادقة من خلال مقدم الهوية الخاص بك، من دون أي خطوات موافقة أخرى.

Keeper SSO Connect المحلي

في حين أن معظم العملاء ينشرون Keeper SSO Connect Cloud، يمكن للعملاء الذين يحتاجون إلى حل في أماكن العمل نشر SSO Connect On-Prem، وهو حل متكامل ذاتي الاستضافة يتطلب خادم تطبيقات مستضافًا إما من Windows أو Linux. وللحفاظ على أمان قائم على أسلوب صفر المعرفة وضمان تجربة تسجيل دخول أحادي سلسة للمستخدمين، يجب تثبيت Keeper SSO Connect على خادم العميل. كما أن بيئات أنظمة تشغيل Windows، وMac، وLinux مدعومة بالكامل من خلال أنماط تشغيل موازنة الأحمال شديدة الإتاحة (HA) والتشفير الفائق باستخدام وحدات أمان الأجهزة.

يولد Keeper SSO Connect كلمة المرور الرئيسية ويحفظها تلقائياً لكل مستخدم مزود، وهي مفتاح 256-bit يولد عشوائياُ. ويتم تشفير كلمة المرور الرئيسية هذه بواسطة مفتاح تسجيل دخول أحادي. ويتم تشفير مفتاح تسجيل الدخول الأحادي بواسطة مفتاح شجري. ويتم استعادة مفتاح تسجيل الدخول الأحادي من الخادم عند بدء تشغيل خدمة Keeper SSO Connect، ثم يتم فك تشفيره باستخدام المفتاح الشجري، والذي يتم تخزينه محلياً على الخادم لدعم بدء التشغيل الخدمة التلقائي. وتتم حماية الاتصالات بين SSO Connect وخزينة أمن سحابة Keeper بواسطة مفتاح نقل. ويتم توقيع اتصالات SAML بتشفير وتتم حمايتها بواسطة خوارزمية توقيع RSA-SHA256 أو ECDSA-SHA256 استناداً إلى نوع مفتاح التشفير (RSA أو ECC) الذي يقدمه المستخدم.

المشاركة

يدعم Keeper القدرة على مشاركة السجلات بأمان بين المستخدمين، بين فريق داخلي أو حتى خارج منظمتهم (إذا كان ذلك مسموحاً به من جانب مسؤول Keeper).

=مشاركة السجلات

يستطيع مستخدمو Keeper مشاركة السجلات مباشرة مع بعضهم البعض. وللقيام بذلك يطلب Keeper بشكل مبدئي المفتاح العام لمنحنى القطع الناقص من خزينة المستخدم. ويوجد لدى كل سجل مفتاح سجل مشفر بواسطة مفتاح عام لمنحني القطع الناقص الخاص بالمتلقي ويتزامن مع خزينة Keeper الخاصة بالمستخدم.

يقوم مالك السجل المشترك المشفر بفك تشفير مفتاح السجل بواسطة المفتاح الخاص لمنحنى القطع الناقص الخاص به. وتتم إعادة تشفير مفتاح السجل بواسطة مفتاح بيانات المستخدم، ويخزن التشفير في خزينة المتلقي.

بنية مشاركة السجلات

مشاركة لمرة واحدة

توفر المشاركة لمرة واحدة من Keeper مشاركة آمنة للسجلات لفترة زمنية محدودة، مثل كلمات المرور أو بيانات الاعتماد أو الأسرار أو الاتصالات أو المستندات أو المعلومات السرية الأخرى، مع أي شخص حتى وإن لم يكن لديه حساب Keeper. حيث يستخدم نموذج تشفير المشاركة لمرة واحدة من Keeper نفس تقنية Keeper Secrets Manager (KSM)، منصة قائمة على أسلوب صفر المعرفة ومبدأ انعدام الثقة لتأمين البنية التحتية للسحابة.

  1. في خزينة Keeper الخاصة بالمستخدم، يقوم المنشئ بتوليد وصول لمرة واحدة عبر النقر على المشاركة لمرة واحدة. ويتم تشفير مفتاح سجل 256-bit AES برمز مميز للوصول لمرة واحدة، ويتم تخزين القيمة المشفرة في خزينة Keeper.
  2. يقوم المستخدم الذي يقوم بمشاركة رمز وصول مميز لمرة واحدة مع شخص متلقٍ باستخدام عنوان URL بسيط أو رمز QR. ويتم الاحتفاظ بجزء عنوان URL الذي يتضمن رمز الوصول المميز في قسم "معرف الجزء" لعنوان URL، والذي لا يتم إرساله إطلاقاً إلى خوادم Keeper. وبناء عليه، لا يستطيع Keeper الوصول إلى المعلومات أو فك تشفيرها مع الاحتفاظ بأسلوب صفر المعرفة.
  3. يتم فتح عنوان URL في متصفح المستخدم، ويتم تحميل تطبيق الخزينة على الجهاز. ثم يتم تسليم الرمز المميز مباشرة إلى تطبيق الخزينة المحلي ولا يتم إرساله إلى الخادم.
  4. يستخدم عندئذ المتلقي جهازه لتوليد زوج مفاتيح منحنى قطع ناقص من جانب المستخدم النهائي، ويتم تخزين المفتاح الخاص محلياً، على الجهاز في مخزن مفتاح التشفير الخاص بالمتصفح.
  5. عند الاستخدام الأول للمتلقي، تقوم مكتبة SDK بالمصادقة مع التجزئة الخاصة بالرمز المميز للوصول لمرة واحدة. ثم يتجاوب خادم Keeper مع نص التشفير الخاص بالسجل المشفر ومفتاح السجل المشفر.
  6. يقوم الجهاز بفك تشفير مفتاح السجل بواسطة رمز وصول لمرة واحدة مميز ويتم فك تشفير المحتويات. ويتم تخزين المفتاح على جهاز العميل في مخزن مفتاح التشفير الخاص بالمتصفح أو في موقع تخزين آخر.
  7. يتم حذف مفتاح السجل المشفر لهذا الجهاز المحدد حتى لا يتم استخدام الرمز المميز مرة أخرى. وبعد ذلك، يجب توقيع طلب العميل بواسطة مفتاح خاص.
  8. يتم إرسال المزيد من الطلبات على نفس الجهاز مع معرف يحدد الجهاز وطلب موقع بمفتاح المستخدم الخاص. يستخدم طلب المعرف الجهاز المحدد عبر توقيع ECDSA المفتاح العام للعميل للجهاز ويتم التحقق منه من قبل الخادم. ويقوم Keeper بمعالجة الطلب، ويعيد الخادم سجلاً مشفراُ في نص مشفر إلى جهاز المستخدم.
  9. علاوة على التشفير على مستوى السجل، ينشئ جهاز العميل مفتاح نقل AES-256 bit مولد عشوائياً، يتم تشفيره بواسطة المفتاح العام لواجهة برمجة تطبيقات سحابة Keeper. ويقوم جهاز العميل بفك تشفير رد الخادم بواسطة مفتاح النقل، ثم يقوم بفك تشفير رد النص المشفر للبيانات الأساسية بواسطة مفتاح السجل والذي يقوم بفك تشفير محتويات السجل.
مشاركة لمرة واحدة

مشاركة المسؤول

تُعد ميزة مسؤول المشاركة من Keeper أذن a تحكم في الوصول قائم على الأدوار (RBAC) يمنح المسؤولين امتيازات متقدمة على المجلدات أو السجلات المشتركة بالمنظمة. ويمتلك مسؤولو المشاركة امتيازات كاملة للمستخدم والسجل لأي سجل مشترك لديهم وصولاً إليه.

مشاركة المسؤول

نموذج تشفير Secrets Manager

Keeper Secrets Manager هو منصة قائمة على أسلوب صفر المعرفة لمحترفي تكنولوجيا المعلومات وDevOps تمكّن الفِرق من إدارة الأسرار عبر دورة حياة تطوير البرنامج ونشره.

نموذج تشفير Keeper Secrets Manager

يستخدم Secrets Manager نموذج التشفير التالي

  • تتم عملية التشفير وفك التشفير محلياً على الجهاز (وليس الخادم).
  • لا يتم تخزين النص العادي على الجهاز مطلقاً.
  • لا يتم تلقي النص العادي على الخادم مطلقاً.
  • لا يستطيع أي شخص فك تشفير الأسرار بما في ذلك موظفو Keeper أو الأطراف الخارجية أو الوسطاء.
  • يدير جهاز العميل المفاتيح الخاصة بتشفير الأسرار وفك تشفيرها، وبتحكم من المستخدم.
  • يتم تشفير كل سر بواسطة مفتاح تشفير 256-bit AES يولد من جانب العميل في نمط GCM.
  • إذا تم تضمين السر في مجلد مشترك، يتم تغليف مفتاح السجل بمفتاح مجلد مشترك.
  • يتم توليد مفتاح تطبيق 256-bit AES على جانب العميل ويستخدم في فك تشفير مفاتيح المجلد والسجل المشتركين. وعندئذ يقوم مفتاح السجل بفك تشفير السر الفردي.
  • يتم تغليف خوادم Keeper بمفتاح 256-bit AES مع TLS لتأمينها من هجمات الوسيط.
  • يولد مفتاح النقل على جهاز العميل وينقل للخادم باستخدام تشفير ECIES عبر مفتاح منحنى القطع الناقص العام للخادم.
  • يستخدم تشفير منحنى القطع الناقص لمشاركة الأسرار بين المستخدمين لتوزيع المفاتيح بشكل آمن.
  • يوفر التشفير متعدد الطبقات تحكماً في الوصول على مستويات المستخدم والمجموعة والمسؤول.
  • يتم تصنيف الأسرار المدارة داخل الخزينة وعزلها في أجهزة مدير أسرار محددة الممنوحة الوصول إلى السجل والمجلد.

نموذج Keeper Secrets Manager لتدوير كلمات المرور

  • يتم تثبيت عميل Keeper Secrets Manager فريد يطلق عليه اسم "بوابة" في بيئة العميل.
  • تنشئ البوابة اتصالاً خارجياً آمناً لموجه Keeper.
  • الموجه هو خدمة سحابية مستضافة في بيئة خدمة أمازون ويب من Keeper، والتي تيسر الاتصالات بين واجهة برمجة تطبيقات Keeper الخلفية وتطبيقات المستخدم النهائي (خزينة الويب، تطبيق سطح المكتب، وما إلى ذلك) والبوابات المثبتة في بيئة المستخدم.
  • يتم إنشاء مقابس ويب بين جهاز المستخدم النهائي (على سبيل المثال خزينة الويب) وموجه Keeper باستخدام الرمز المميز للجلسة الحالية.
  • يتحقق موجه Keeper من الرمز المميز للجلسة ويصادق الجلسة. ويتم تغليف كل البيانات الأساسية المشفرة المرسلة إلى موجه Keeper بواسطة مفتاح 256-bit AES، بالإضافة إلى TLS للحماية من هجمات الوسيط.
  • يتم إنشاء مفتاح 256-bit AES على جهاز المستخدم النهائي وينقل إلى الخادم بواسطة تشفير ECIES عبر مفتاح منحنى القطع الناقص العام للموجه.
  • يتم إنشاء طلبات التدوير والاكتشاف بين جهاز المستخدم النهائي (أو مجدول Keeper) والبوابة عبر قناة اتصالات مقبس الويب القائمة.
  • خلال التدوير، عند طلب البوابة لسر من خزينة Keeper، تقوم بمصادقة السر وفك تشفيره باستخدام واجهات برمجة تطبيقات Keeper Secrets Manager للحفاظ على أسلوب صفر المعرفة.
  • مثل أي جهاز إدارة أسرار آخر، يمكن حظر الوصول استناداً إلى عنوان IP، بالإضافة إلى عملية التشفير والتوقيع.
الرسم البياني للبنية التحتية لتدوير كلمة المرور

الاتصال القائم على مبدأ انعدام الثقة وأمان الأنفاق

توفر KeeperPAM القائمة على مبدأ انعدام الثقة القدرة على إنشاء جلسات مميزة على السحابة وفي منشآت المؤسسة وإنشاء أنفاق وإنشاء وصول مباشر إلى البنية التحتية ووصول آمن إلى قاعدة البيانات عن بُعد من دون استخدام شبكة افتراضية خاصة.

الاتصال هو جلسة بصرية عن بُعد باستخدام متصفح الويب. يكون التفاعل بين المستخدم والجهاز المستهدف من خلال نافذة متصفح ويب أو داخل تطبيق Keeper Desktop.

النفق هو اتصال TCP/IP يتم إنشاؤه بين عميل الخزينة المحلي من خلال Keeper Gateway إلى نقطة النهاية المستهدفة. يمكن للمستخدم استخدام أي تطبيق أصلي للتواصل مع نقطة النهاية المستهدفة، مثل محطة سطر الأوامر، أو تطبيق واجهة المستخدم الرسومية أو تطبيق إدارة قاعدة البيانات مثل MySQL Workbench.

عندما ينشئ المستخدم اتصالاً أو نفقًا:

  1. يتصل تطبيق Vault Client بالبنية التحتية لـ Keeper Router لبدء اتصال WebRTC محمي بمفتاح متماثل لـ ECDH ومخزَّن في سجل Keeper ذي الصلة.
  2. تتواصل Keeper Gateway مع Keeper Router من خلال مقابس ويب صادرة فقط. ويرد في هذا الرابط وصف تفصيلي لذلك.
  3. تستخدم Keeper Gateway واجهات برمجة التطبيقات لـ Keeper Secrets Manager لاسترداد الأسرار الضرورية من الخزنة، بما في ذلك المفتاح المتماثل لـ ECDH.
  4. بالنسبة إلى Connections، يعمل Vault Client (باستخدام بروتوكول Apache Guacamole) على تمرير البيانات عبر اتصال WebRTC إلى Keeper Gateway التي تستخدم بعد ذلك Guacd للاتصال بالوجهة الموجودة في سجل Keeper.
  5. بالنسبة إلى ميزات إنشاء المسارات الآمنة (إعادة توجيه المنفذ)، يتم فتح منفذ محلي على الجهاز المحلي الذي يشغل برنامج Keeper Desktop. يتم نقل البيانات المُرسلة إلى المنفذ المحلي من خلال اتصال WebRTC إلى Keeper Gateway ويتم توجيهها لاحقًا إلى نقطة النهاية المستهدفة المحددة في سجل Keeper.
  6. تتم حماية تسجيلات الجلسات الخاصة بالاتصالات بواسطة مفتاح تشفير AES-256 ("مفتاح التسجيل") الذي يتم إنشاؤه على Keeper Gateway في كل جلسة. بالإضافة إلى ذلك، يتم تغليف مفتاح التسجيل بواسطة مفتاح موارد AES-256 مشتق من HKDF.

الاتصال القائم على مبدأ انعدام الثقة وأمان الأنفاق

أمان عزل المتصفح عند بُعد

تحمي تقنية عزل المتصفح عن بُعد من Keeper الوصول إلى تطبيقات الويب الداخلية أو أي أصول أخرى قائمة على الويب من خلال حاوية Keeper Connection Manager Docker أو من خلال Keeper Gateway.

استخدام طريقة حاوية Connection Manager Docker:

  1. يقوم المستخدم بالمصادقة في خدمة الويب الخاصة بـ Keeper Connection Manager، والتي يستضيفها العميل في حاوية Docker.
  2. يطلق المستخدم جلسة عزل المتصفح عن بُعد لتطبيق الويب المستهدف. بين متصفح المستخدم وخدمة الويب المستضافة من Keeper Connection Manager، يكون الاتصال عبر HTTPS محميًا بواسطة Let's Encrypt أو الشهادة المحددة للعميل.
  3. في حاوية Keeper Connection Manager Docker، يتم تنفيذ إصدار مضمن من Chromium داخل ملعب، ويتم عرض موقع الويب المستهدف باستخدام برنامج تشغيل عرض محلي ينقل المحتوى المرئي للصفحة في الوقت الفعلي إلى متصفح الويب الخاص بالمستخدم باستخدام بروتوكول Apache Guacamole.

استخدام Keeper Gateway مع Keeper Web Vault أو تطبيق Desktop من Keeper:

  1. يتصل تطبيق Vault Client بالبنية التحتية لـ Keeper Router لبدء اتصال WebRTC محمي بمفتاح متماثل لـ ECDH ومخزَّن في سجل Keeper ذي الصلة.
  2. تتواصل Keeper Gateway مع Keeper Router من خلال مقابس ويب صادرة فقط. ويرد في هذا الرابط وصف تفصيلي لذلك.
  3. تستخدم Keeper Gateway واجهات برمجة التطبيقات لـ Keeper Secrets Manager لاسترداد الأسرار الضرورية من الخزنة، بما في ذلك المفتاح المتماثل لـ ECDH.
  4. يعمل Vault Client (باستخدام بروتوكول Apache Guacamole) على تمرير البيانات عبر اتصال WebRTC إلى Keeper Gateway التي تستخدم بعد ذلك HTTP أو HTTPS للاتصال بالوجهة الموجودة في سجل Keeper.
  5. تتم حماية تسجيلات الجلسات الخاصة بالاتصالات بواسطة مفتاح تشفير AES-256 ("مفتاح التسجيل") الذي يتم إنشاؤه على Keeper Gateway في كل جلسة. بالإضافة إلى ذلك، يتم تغليف مفتاح التسجيل بواسطة مفتاح موارد AES-256 مشتق من HKDF.
أمان عزل المتصفح عند بُعد

حماية عزل المتصفح

يتم تنشيط عدة تدابير أمنية باستخدام بروتوكول عزل المتصفح عن بُعد:

  1. تكون نقطة نهاية تطبيق الويب المحمية مغلفة بطبقة من تشفير TLS من بوابة Keeper Connection Manager إلى الجهاز المحلي للمستخدم، بغض النظر عما إذا كان TLS يستخدم بين البوابة ونقطة النهاية - مما يحمي من هجمات MITM أو فحص الحزم على الشبكة المحلية للمستخدم.
  2. تقوم جلسة التصفح عن بُعد بعرض التفاعل بصريًا على الجهاز المحلي للمستخدم باستخدام لوحة وعرض رسومي. لا يتم تنفيذ أي رمز JavaScript أو HTML من موقع الويب المستهدف على الجهاز المحلي للمستخدم.
  3. نظرًا لأنه لا يتم تنفيذ أي رمز موقع ويب من الهدف محليًا وأنه يتعذر على المتصفح المحلي الوصول مباشرة إلى رمز التطبيق الأساسي، فإن تطبيق الويب المعزول محمي من شتى أساليب الهجوم، مثل الثغرات الأمنية المتعلقة بالبرمجة عبر المواقع، وتزوير الطلبات عبر المواقع، وإساءة استخدام واجهة برمجة التطبيقات.
  4. يمكن تقييد إجراءات المستخدم النهائي ومنعه من إجراء عملية سحب للبيانات من نقطة النهاية المستهدفة من خلال عنوان URL وتصفية طلبات الموارد. يتم تقييد عمليات تحميل الملفات وتنزيلها، حتى لو كان تطبيق الويب المستهدف يسمح بالقيام بالإجراء بخلاف ذلك.
  5. يمكن تسجيل جلسة التصفح ونقرات المفاتيح لأغراض التدقيق والامتثال، مما يوفر القدرة على إجراء تحليل جنائي للجلسات القائمة على الويب.
  6. لا يتم أبدًا نقل بيانات الاعتماد التي يتم ملؤها تلقائيًا من البوابة إلى تطبيق الويب المستهدف أبدًا إلى جهاز المستخدم، ولا يمكن للمستخدم الوصول إليها على جهازه المحلي، مما يحمي من التسرب السري.
  7. من خلال سياسات جدار الحماية، يمكن مطالبة المستخدم بالوصول إلى تطبيق الويب المستهدف فقط من خلال جلسة عزل المتصفح عن بُعد، مما يقلل من التهديد الناجم عن متصفح مخترق أو برنامج ضار في الجهاز المحلي.
  8. يصبح تطبيق الويب المستهدف محميًا من خلال تسجيل الدخول الأحادي و/أو المصادقة متعددة العوامل، حتى لو كان التطبيق لا يدعم ذلك بالأصل. تحمي Keeper الوصول إلى الخزينة وأي جلسات لعزل المتصفح عن بُعد من خلال طرق المصادقة المتقدمة الموضحة في هذا المستند.
حماية عزل المتصفح

BreachWatch®

يشغل Keeper بنية مدارة ومحتواه ذاتياً على خدمة أمازون ويب يطلق عليها اسم BreachWatch. وBreachWatch منفصلة مادياً عن واجهة برمجة تطبيقات Keeper وسجلات المستخدم.

يتم استخدام نموذج أمن جهاز مادي على خوادم BreachWatch لمعالجة المليارات من كلمات المرور الفريدة من عمليات اختراق بيانات الشبكة المظلمة وتجزئتها وتخزينها. وتتم معالجة كل كلمات المرور على خوادم Keeper باستخدام طريقة تجزئة HMAC_SHA512 وتجزء بواسطة نماذج أمن الأجهزة باستخدام مفتاح غير قابل للتصدير.

عند تفعيل BreachWatch على الجهاز العميل، يتم توليد تجزئة HMAC_SHA512 استناداً إلى كل سجل وترسل إلى الخادم. ويتم إنشاء تجزئة ثانية على الخادم باستخدام HMAC_SHA512 عبر نماذج أمن الأجهزة باستخدام مفتاح غير قابل للتصدير. وتتم مقارنة "تجزئة التجزئة" لمعرفة ما إذا كان قد تم اختراق بيانات اعتماد.

تم إنشاء بنية BreachWatch لمنع ارتباط كلمة مرور مخترقة بكلمة مرور في خزينة المستخدم، وبغض النظر عن حجم البيانات المخترقة. يستخدم اكتشاف كلمات المرور المخترقة نموذج أمن الأجهزة المادي للتأكد من أن تتم التجزئة عبر الإنترنت فقط، لمنع أي هجمات قوة غاشمة على البيانات.

  • يتم تجزئة كلمات المرور بواسطة HMAC_512 مرتين: مرة على جهاز العميل باستخدام "pepper"، ومرة على CloudHSM الخاص بخدمات أمازون ويب باستخدام نموذج أمن جهاز ما بواسطة مفتاح غير قابل للتصدير.
  • يتم استخدام HMAC_512 حيث إنه يستفيد من ميزة التجزئة القوية بالإضافة إلى مفتاح سري غير قابل للتصدير. وبناء عليه لا يمكن الهجوم من دون إنترنت على التجزئة.
  • يمدد رمز مصادقة الرسائل (MAC) مع نتيجة وظيفة تجزئة التشفير استخدام وظائف التجزئة. ولا تستند نتائجه على الرسائل فقط، بل أيضاً على المدخل الثاني الذي يمكن أن يكون مفتاحاً سرياً.

تم إنشاء BreachWatch من قبل Keeper بنسبة 100% باستخدام تغذية بيانات SpyCloud، ولكن لا يرسل Keeper أي بيانات لأطراف خارجية مطلقاً.

نموذج Keeper BreachWatch

فحص المجال

يقوم عملاء BreachWatch بتنزيل قائمة بالمجالات التي تم اختراقها وإجراء الفحص محلياً.

فحص أسماء المستخدمين وكلمات المرور

تتصل أجهزة العميل مع BreachWatch وتحمل قائمة بأسماء المرور (أو كلمات المرور) المجزئة مع معرف عشوائي محدد من جانب العميل (معرفات منفصلة لخدمات التحقق من أسماء المستخدم وكلمات المرور). تتم معالجة تجزئة كلمات المرور هذه عند تحميل HMAC باستخدام نموذج أمن الجهاز (HSM) ويخزن مفتاح سري في نموذج أمن الجهاز المحدد على إنه غير قابل للتصدير (مما يعني أن نموذج أمن الجهاز سيعالج HMAC محلياً فقط ولا يمكن تصدير المفتاح). وتتم مقارنة مدخلات HMAC (أسماء المستخدمين أو كلمات المرور) مقابل مجموعات البيانات المخترقة التي تم معالجتها بنفس HMAC والمفتاح. ويتم الإبلاغ عن أي تطابق إلى جهاز العميل. ويتم تخزين أي قيم غير متطابقة مع هوية المستخدم المجهولة.

وبينما يتم إضافة أسماء المستخدمين وكلمات المرور إلى النظام، تتم أيضاً معالجتها بواسطة HMAC على نموذج أمن الجهاز، وتضاف إلى مجموعات بيانات BreachWatch وتقارن مقابل قيم العميل المخزنة. وترسل أي تطابقات تنبيهاً إلى هوية هذا العميل.

يقوم العملاء بشكل دوري بتسجيل الدخول إلى BreachWatch وعرض معرفاتهم الخاصة بـ BreachWatch. يتم تنزيل أي رسائل مجدولة ويقوم العملاء بتحميل أي أسماء مستخدمين وكلمات مرور جديدة أو تم تغييرها ليتم معالجتها بنفس الطريقة

يقوم أمان خدمات BreachWatch على نموذج "ثقة عند الاستخدام الأول (TOFU، ما يعني أن العملاء يجب أن يفترضوا أن خادم BreachWatch ليس ضاراً (بمعنى أنه لا يتعرض للاختراق بشكل فعال من قبل أي متطفل) عندما يقوم العميل بتحميل قيمه المجزأة. بمجرد معالجة هذه القيم باستخدام وحدة جهاز أمني يتم تأمينها ضد محاولات الاختراق تتم دون الاتصال بالإنترنت. وبعبارة أخرى، إذا قام أحد المتطفلين بسرقة مجموعة بيانات قيم العملاء المخزنة، فلا يستطيع اختراق هذه القيم دون اتصال بالإنترنت دون مفتاح HMAC المخزن في وحدة الجهاز الأمني.

إذا ما تم اكتشاف كلمة مرور مخترقة، يرسل جهاز العميل تجزئة مزيج اسم المستخدم + كلمة المرور إلى خوادم BreachWatch والتي تقوم عندئذ بنفس مقارنة تجزئة HMAC لتحديد ما إذا كان قد تم اختراق مزيج اسم المستخدم +كلمة المرور، وإن كان الأمر كذلك، تتم إعادة المجالات المتعلقة بعمليات الاختراق هذه، ليتمكن جهاز العميل من تحديد إذا ما تطابق اسم المستخدم +كلمة المرور +المجال. إذا تطابقت المعلمات الثلاثة على جهاز العميل، يتم تنبيه المستخدم بخطورة عملية الاختراق.

BreachWatch للعملاء من الشركات والمؤسسات

عند تفعيل BreachWatch لعملاء الشركات والمؤسسات، يتم مسح خزائن المستخدم النهائي تلقائياً في كل مرة يقوم مستخدم بتسجيل الدخول بواسطة Keeper. ويكون ملخص البيانات التي يتم فحصها من BreachWatch مشفراً على جهاز المستخدم بواسطة المفتاح العام للمؤسسة ويتم فك التشفير من خلال مسؤول المؤسسة عند تسجيل الدخول إلى وحدة تحكم المسؤول من Keeper. وتتضمن هذه المعلومات المشفرة عنوان البريد الإلكتروني وعدد السجلات شديدة الخطورة وعدد السجلات المحلولة وعدد السجلات المهملة. ويتمكن مسؤول Keeper من عرض احصائيات ملخصة على مستوى المستخدم داخل واجهة مستخدم وحدة تحكم المسؤول.

تسجيل الأحداث والإبلاغ عنها

عند تكامل أجهزة المستخدم النهائي من Keeper مع إعداد التقارير والتنبيهات المتقدمة، قد يتم تهيئتها اختيارياً لنقل أحداث مفصلة في الوقت الفعلي لحلول SIEM خارجية وواجهة إعداد تقارير وحدة تحكم المسؤول من Keeper. وتتضمن بيانات الحدث عنوان البريد الإلكتروني وUID الخاص بالسجل، وعنوان IP ومعلومات الجهاز (لا تتضمن الأحداث أي بيانات سجل تم فك تشفيرها، حيث إن Keeper هو منصة قائمة على أسلوب صفر المعرفة ولا يمكن فك تشفير بيانات المستخدم).

افتراضياً لا يتم إرسال بيانات أحداث BreachWatch التفصيلية إلى نموذج إعداد التقارير والتنبيهات المتقدم أو أي أنظمة تسجيل دخول خارجية متصلة. لتفعيل إعداد التقارير على مستوى الحدث الخاص ببيانات BreachWatch لنموذج إعداد التقارير والتنبيهات المتقدم، يجب عليك تمكين سياسة إنفاذ دور الحدث تحت الدور الخاص (specific role) > سياسات الإنفاذ (Enforcement Policies) > شاشة ميزات الخزينة (Vault Features). وفور تشغيلها تبدأ أجهزة عميل المستخدم النهائي في إرسال بيانات الحدث هذه. وحيث إن التكامل مع حلول SIEM الخارجية ينتقل من خلفية Keeper إلى SIEM المستهدف، فيمكن بالتالي قراءة معلومات من خلال SIEM المستهدف ويمكن استخدامها لتحديد السجلات والمستخدمين الذين لديهم كلمات مرور عالية الخطورة داخل المنظمة. وإذا كان مسؤول Keeper لا يرغب في نقل بيانات الحدث على مستوى السجل إلى نموذج إعداد التقارير والتنبيهات المتقدم من Keeper، فيمكن ترك هذا الإعداد معطلاً.

SplunkSplunk Sumo LogicSumo Logic LogRhythmLogRhythm Syslog PushSyslog Push IBM QRadarIBM QRadar Azure SentinelAzure Sentinel AWS S3 BucketAWS S3 Bucket DevoDevo DatadogDatadog Logz.ioLogz.io ElasticElastic

وضع عدم الاتصال بالإنترنت

يمكن نمط العمل من دون إنترنت المستخدمين من الحصول على وصول إلى خزائنهم عندما لا يتمكنوا من الاتصال بـ Keeper أو بموفر هوية تسجيل الدخول الأحادي عبر الإنترنت. وهذه الإمكانية متاحة على تطبيق الهاتف الجوال وتطبيق سطح المكتب وتطبيق الويب عبر كل المتصفحات من Keeper.

وضع عدم الاتصال بالإنترنت

تعمل هذه الإمكانية عبر نسخ نسخة من الخزينة محلياً على جهاز المستخدم. ويتم تشفير بيانات الخزينة المخزنة من دون إنترنت باستخدام AES-GCM مع "مفتاح عميل" 256-bit يتم توليده عشوائياً ويحمي بواسطة PBKDF2-HMAC-SHA512 مع 1,000,000 تكرار وتشفير عشوائي. ويتم تخزين التشفير والتكرارات محلياً. وعند إدخال المستخدم لكلمة مروره الرئيسية أو استخدامه للمقاييس الحيوية، يتم اشتقاق مفتاح باستخدام التشفير والتكرارات وتتم محاولة فك تشفير مفتاح العميل. ويتم عندها استخدام مفتاح العميل لفك تشفير ذاكرة التخزين المؤقت للسجل المخزن. وإذا كان هناك حماية تدمير ذاتي مفعلة على خزينة المستخدم، فسيتم مسح كل بيانات الخزينة المخزنة محلياً بشكل تلقائي بعد 5 محاولات تسجيل دخول فاشلة. وفيما يتعلق بعملاء الشركات، يمكن حظر الوصول من دون إنترنت استناداً إلى سياسات إنفاذ الأدوار من قبل مسؤول Keeper.

الوصول في حالات الطوارئ (الإرث الرقمي)

تمكن خطط الأفراد والعائلة من Keeper المستخدمين من إضافة ما يصل إلى خمس جهات اتصال لمنح الوصول للخزينة في حالة وفاة المستخدم أو أي حالات طوارئ أخرى. ويحدد المستخدم وقت انتظار، وفور انقضاء هذا الوقت تحصل جهة الاتصال في حالة الطوارئ على الوصول لخزينة المستخدم. وتقوم مشاركة الخزينة مع جهة اتصال في حالة الطوارئ على أسلوب صفر المعرفة، ولا يتم مشاركة كلمة المرور الرئيسية للمستخدم مطلقاً. علاوة على ذلك، يتم استخدام تشفير 2048-bit RSA مع مفتاح 256-bit AES. ويجب أن يكون لدى جهة الاتصال في حالة الطوارئ حساب في Keeper لقبول المعلومات.

ميزة الوصول في حالة الطوارئ

بنية الشبكة

يستخدم Keeper خدمة أمازون ويب في أمريكا الشمالية (السحابة التجارية أو الحكومية)، وأوروبا، وأستراليا، واليابان، وكندا لخصوصية بيانات ذات طابع محلي وعزل جغرافي لاستضافة حل وبنية Keeper وتشغيلهما. كما أن استخدام خدمة أمازون ويب يمكن Keeper من أن يقوم بتوسيع نطاق المصادر حسب الاقتضاء وتزويد العملاء ببيئة التخزين السحابي الأسرع والأكثر أماناً بسلاسة. ويشغل Keeper كل من البيئات متعددة الأوقات والمتعددة المناطق لتعظيم وقت التشغيل وتوفير أسرع وقت استجابة للعملاء. ويمكن أن يستضيف عملاء المؤسسات مستأجر Keeper الخاص بهم في أي منطقة أساسية. ويتم عزل بيانات العميل ووصوله للمنصة إلى هذه المنطقة المحددة.

مصادقة السحابة

قام Keeper بإنشاء نموذج مصادقة سحابية واتصالات الشبكة متقدم، وقد تم إنشاؤه للحصول على أعلى مستويات الخصوصية والأمت والثقة. وفيما يلي بعض من الميزات الرئيسية لنموذج المصادقة:

  • لا يتم نقل كلمة المرور الرئيسية عبر طبقة الشبكة مطلقاً. بخلاف معظم خدمات SaaS، ولا تغادر بيانات اعتماد تسجيل الدخول الجهاز مطلقاً. ويستخدم PBKDF2 على الجهاز المحلي لاشتقاق مفتاح 256-bit AES المستخدم لفك التشفير. ويتم توليد مفتاح PBKDF2 ثاني محلياً ثم يتم تجزئته بواسطة HMAC_SHA256 لاشتقاق رمز مصادقة مميز. يوجد لدى خزينة Cloud Security من Keeper صفر معرفة بمفتاح فك تشفير المستخدم.
  • لا يمكن اعتراض نقل البيانات بين جهاز العميل وسحابة Keeper. أو فك تشفيرها، ويستخدم Keeper تثبيت المفاتيح وطبقات إضافية من التشفير على مستوى الشبكة (مفاتيح النقل) بين الجهاز وخوادم Keeper لضمان منع هجمات الوسيط.
  • لا يمكن أن يتم تسجيل الدخول لحساب من جهاز جديد من دون خطوة تحقق من الجهاز. حيث لا يمكن إجراء محاولات لتسجيل الدخول على حساب من دون اجتياز هذه الخطوة. ويدعم Keeper العديد من طرق التحقق من الأجهزة والتي تستند إلى برنامج المصادقة المستخدم.
  • تتم المصادقة الثنائية بعد التحقق من الجهاز وقبل إدخال كلمة المرور الرئيسية. إذا كان لدى مستخدم مصادقة ثنائية مثبتة أو مفروضة، فيجب اجتياز هذه الخطوة قبل إدخال كلمة المرور الرئيسية.
  • لا يمكن إدخال كلمة المرور الرئيسية حتى نجاح خطوة التحقق من الجهاز والمصادقة الثنائية. حيث لا يستطيع المستخدم الوصول إلى خطوة إدخال كلمة المرور الرئيسية من دون التحقق من الجهاز والقيام بالمصادقة الثنائية أولاً. ويوفر مسار المصادقة المتقدمة هذا حماية من العديد من نواقل الهجمات بما في ذلك هجوم القوة الغاشمة ورش كلمات المرور والتعداد والوسيط.

التشفير أثناء الانتقال

يتم حماية خزينة أمن السحابة من Keeper بواسطة واجهات برمجة التطبيقات والتي يتم التحقق منها عبر التفويض من جهاز العميل. حيث يستعيد العميل رمز جلسة مميز عند تسجيل الدخول ويرسله مع كل استدعاء لواجهة برمجة التطبيقات. ويتم تعقب رمز الجلسة المميز على الخادم. ويتم تسجيل الدخول عبر كلمة المرور الرئيسية أو استئناف الجلسة أو مصادقة تسجيل دخول أحادي SAML 2.0.

عند استخدام كلمة المرور الرئيسية، يقوم جهاز العميل باشتقاق "مفتاح مصادقة" 256-bit باستخدام PBKDF2-HMAC-SHA256 مع 1,000,000 تكرار وتشفير 128-bit عشوائي. يتم توليد "تجزئة مصادقة" عبر تجزئة مفتاح المصادقة باستخدام SHA-256. ولتسجيل الدخول تتم مقارنة تجزئة المصادقة مقابل تجزئة المصادقة المخزنة على خزينة أمن السحابة. وبعد تسجيل الدخول يتم توليد رمز جلسة مميز على الخادم ويرسل للعميل ليتم استخدامه من قبل جهاز العميل لطلبات واجهة برمجة التطبيقات اللاحقة. ويجب أن تكون الجلسة نشطة للسماح باستمرار استخدام العميل لاتصالات الخادم.

يدعم Keeper 256-bit و128-bit TLS لتشفير كل بيانات النقل بين تطبيق العميل والتخزين القائم على السحابة من Keeper.

ينشر Keeper اعتمادات TLS الموقعة من DigiCert باستخدام خوارزمية SHA2، خوارزمية التوقيع الأكثر أماناً وتعرض في الوقت الحالي من قبل سلطات الاعتماد التجارية. SHA2 أكثر أماناً بشكل أكبر من SHA1 المستخدم على نطاق واسع، والذي قد يتم استغلاله بسبب الضعف الحسابي المحدد في الخوارزمية. ويساعد SHA2 في الحماية من إصدار اعتمادات مزورة قد يستخدمها المهاجم لانتحال صفة موقع ويب.

يدعم Keeper أيضاً شفافية الاعتماد (CT) وهي مبادرة أطلقتها شركة جوجل لإنشاء سجل قابل للتدقيق العام يضم الاعتمادات الموقعة من سلطات الاعتماد. حيث تساعد شفافية الاعتماد في الحماية من إصدار اعتمادات من كيانات غير مفوضة. وشفافية الاعتماد مدعومة الآن في الإصدارات الأحدث من متصفحات الويب كروم وسفاري بريف. يمكن العثور على المزيد من المعلومات حول شفافية الاعتماد على https://certificate.transparency.dev/. ويدعم Keeper مجموعات تشفير TLS التالية:

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES128-SHA256
  • ECDHE-RSA-AES128-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES256-SHA384
  • ECDHE-RSA-AES256-SHA384

تطبيق أجهزة عميل Keeper على أنظمة تشغيل iOS وAndroid تثبيت المفاتيح أيضاً، وهي آلية أمن تمنع الانتحال من قبل المهاجمين باستخدام اعتمادات رقمية مزورة.

الحماية من هجمات البرمجة عبر المواقع (XSS)

تطبق خزينة الويب التي يوفرها Keeper سياسة أمان صارمة للمحتوى تضيع قيوداً على نقطة إصدار الطلبات الصادرة وتمنع تنفيذ جميع البرامج النصية، باستثناء تلك الصادرة صراحةً من Keeper، بما في ذلك البرامج النصية المضمنة وسمات HTML التي تعالج الأحداث، وهو ما يؤدي إلى تقليص معظم متجهات هجمات البرمجة عبر المواقع أو القضاء عليها تماماً.

يقتصر الوصول إلى أسماء مجال Keeper إلى HTTPS بواسطة TLS 1.3 ويفرض بواسطة أمن النقل الصارم HTTP (HTTP Strict Transport Security). ويمنع ذلك مجموعة واسعة من التقاط حزم البيانات المارة بالشبكات وتعديل البيانات وهجمات الوسيط.

داخل ملحق متصفح Keeper، لن يقوم Keeper بمطالبة المستخدمين ببيانات اعتماد خزائنهم من منطقة إطار الصفحة. حيث يتم تسجيل الدخول إلى الملحق من منطقة شريط أدوات ملحق المتصفح داخل المتصفح. ويتم تسجيل الدخول إلى الخزينة على متصفح الويب دائماً إما على مجال keepersecurity.com أو keepersecurity.eu، أو keepersecurity.com.au، أو keepersecurity.jp، أو keepersecurity.ca، أو govcloud.keepersecurity.us، أو من شريط أدوات ملحق متصفح Keeper الموجود خارج صفحة المحتوى.

ملحق متصفح Keeper يضع iFrame في نماذج تسجيل الدخول لصفحة ويب لضمان عدم وصول مواقع الويب الضارة إلى المحتوى المضخوخ. يتم أيضاً حصر محتوى السجل المضخوخ في iFrames على سجلات الخزينة المخزنة في خزينة المستخدم والتي تطابق مجال موقع الويب المستهدف. ولن يعرض Keeper الملء التلقائي لبيانات تسجيل الدخول أو كلمة المرور إلا إذا تطابق مجال موقع الويب مع حقل مجال موقع الويب في سجل خزينة Keeper. ولن يعرض الملحق سجلات إلا إذا تطابقت السجلات مع جذر مجال عنوان موقع الويب.

قد تحصل ملحقات المتصفح الخارجية على أذونات متقدمة في متصفحات الويب ويمكنها الوصول إلى معلومات داخل الصفحة. وبناء عليه يوصى أن يمنع مسؤولي Keeper المستخدمين من تثبيت ملحقات متصفح خارجية من متجر التطبيقات الخاص بالمتصفح.

المقاييس الحيوية

يدعم Keeper بشكل أساسي Windows Hello، وبصمة الإصبع، وبصمة الوجه، والمقاييس الحيوية لنظام تشغيل Android. كما يستطيع العملاء الذين يقومون عادة بتسجيل الدخول إلى خزينة Keeper الخاصة بهم باستخدام كلمة المرور الرئيسية أو تسجيل دخول بواسطة تسجيل الدخول الأحادي للمؤسسة (SAML 2.0)، أن يقوموا بتسجيل الدخول إلى أجهزتهم باستخدام مقياس حيوي. ويجب تمكين المقاييس الحيوية من خلال مسؤول Keeper في سياسة الأدوار. كما يمكن تحقيق الوصول من دون إنترنت بواسطة المقاييس الحيوية لكل من مستخدمي كلمة المرور الرئيسية والذين لديهم تسجيل دخول أحادي ممكن عند تفعيل هذه الميزة.

عند تمكين تسجيل الدخول بالمقاييس الحيوية على الجهاز، يتم توليد مفتاح عشوائي بشكل محلي ويخزن في القطاع الآمن (على سبيل المثال سلسلة المفاتيح أو متجر المفاتيح) بالجهاز. ويتم تشفير مفتاح بيانات المستخدم بمفتاح المقاييس الحيوية. وعند نجاح المصادقة بالمقاييس الحيوية، يتم استعادة المفتاح ويتمكن المستخدم من فك تشفير خزينته.

سلسلة مفاتيح iOS، وبصمة الإصبع، وبصمة الوجه

تسمح بصمة الإصبع وبصمة الوجه على الأجهزة التي تعمل بنظام تشغيل iOS للمستخدمين الوصول إلى خزينة Keeper باستخدام المقاييس الحيوية. لتوفير هذه الميزة المريحة، يتم تخزين "مفتاح مقاييس حيوية" مولد عشوائياً في سلسلة المفاتيح الخاص بنظام تشغيل iOS. ولا يتم تعيين عنصر سلسلة مفاتيح iOS المنشئ لهذه الوظيفة ليقوم بالمزامنة مع iCloud سلسلة المفاتيح وبناء عليه لن يغادر جهازك الجوال الذي يعمل بنظام تشغيل iOS.

يوصي بشدة أن تستخدم كلمة مرور رئيسية معقدة وتمكن المصادقة متعددة لعوامل لتوفر أقصى قدر ممكن من الأمان لخزينة Keeper المشفرة الخاصة بك. واستخدام بصمة الإصبع وبصمة الوجه يجعل استخدام كلمة مرور رئيسية معقدة أكثر ملائمة على جهازك الجوال الذي يعمل بنظام تشغيل iOS. كما يوصى بأن تضبط رمز مرور أكبر من الحد الأدنى البالغ 4 أرقام لتأمين سلسلة مفاتيح iOS.

يتم استخدم سلسلة مفاتيح iOS من قبل نظام تشغيل iOS والتطبيقات لتخزين بيانات الاعتماد بأمان. حيث تقوم تطبيقات iOS باستخدام سلسلة مفاتيح iOS لتخزين مجموعة متنوعة من المعلومات الحساسة بما في ذلك كلمات مرور مواقع الويب والمفاتيح وأرقام بطاقات الائتمان ومعلومات Apple Pay. بينما لا يقوم Keeper باستخدام سلسلة مفاتيح iOS المفاتيح لتخزين سجلات Keeper، بل تتم حماية كل سجلات Keeper بواسطة تشفير 256-bit AES وتخزن بأمان في خزينة Keeper. كما يتم تشفير سلسلة مفاتيح iOSبتشفير 256-bit AES باستخدام رمز مرور الجهاز. وحتى إن تم فقدان الجاهز أو سرقته أو حصل المهاجم على وصل مادي للجهاز الجوال، فلن يتمكن من الوصول إلى أي معلومات مخزنة من Keeper. حيث لا يمكن فك تشفير سلسلة مفاتيح iOS من دون رمز المرور ولا يمكن فك تشفير خزينة Keeper من دون كلمة مرور المستخدم الرئيسية لـ Keeper.

Apple Watch®

تسمح ميزة التفضيل في Apple Watch بعرض السجلات المحددة في Apple Watch المقترنة. يجب أن يتم تمكين سجلات Keeper صراحةً للسماح بالعرض على Apple Watch. وتتواصل Apple Watch المقترنة مع ملحق Keeper Watch والذي يعمل بشفافية في فراغ تحديد آلية وصول مستقل عن تطبيق Keeper لنظام iOS. كما يستخدم ملحق Keeper Watch سلسلة مفاتيح iOS من أجل التخزين والوصول الآمنين للمفاتيح لتمكينه من التواصل بسلاسة وأمان مع تطبيق Keeper لنظام iOS.

Keeper DNA®

يوفر Keeper DNA طريقة مصادقة متعددة العوامل باستخدام جهاز ساعة ذكية. ويستخدم Keeper DNA رموز الأمان المميزة المخزنة في خزينة Keeper لتوليد رموز مستندة إلى الوقت للمصادقة متعددة العوامل. ويمكن اعتماد طلبات المصادقة المستندة إلى الوقت هذه وإرسالها مباشرة من Apple Watch (أو جهاز Android Wear) عبر نقرة على شاشة الساعة أو إدخاله يدوياً من خلال المستخدم.

إلغاء إلحاق الموظف (نقل الخزينة)

عند تفعيل سياسة نقل حساب لعقدة، يتم إنشاء سياسة العقدة لزوج مفاتيح عام/خاص في وحدة تحكم المسؤول على جهاز المستخدم. يتم تشفير مفتاح بيانات المستخدم النهائي للمستخدمين في الدور المطبق عليهم الإنفاذ، باستخدام المفتاح العام للسياسة عند تسجيل المستخدم الدخول إلى الخزينة. ويتم تشفير المفتاح الخاص باستخدام المفتاح العام للمسؤول ويمكن أن يقوم المسؤول عند ذلك بفك تشفير مفتاح إنفاذ الدور مع نقل الخزينة.

عند نقل الخزينة، يجب أن يقفل مسؤول Keeper حساب المستخدم أولاً. ويتم بعدها نقل الخزينة فورياُ، ويتبع ذلك حذف حساب المستخدم. ويضمن ذلك ألا تتم العملية في الخفاء. وعند القيام بالنقل يتم استعادة مفتاح بيانات المستخدم عبر فك تغليف المفتاح الخاص لإنفاذ الدور أولاً ثم فك تغليف مفتاح بيانات المستخدم. ويستخدم مفتاح البيانات لفك تغليف مفاتيح السجل، ومفاتيح الفريق، ومفاتيح المجلد.

تتم كل عمليات التشفير من جانب العميل من داخل وحدة تحكم المسؤول، وتتوفر لدى Keeper القدرة على فك تشفير المعلومات التي تتم مشاركتها أو نقلها خلال وقت لا يذكر. علاوة على ذلك، تتم مشاركة مفتاح بيانات العميل الخاص بالمستخدم في وقت لا يذكر. ولن يتلقى أي مستخدم يتم إزالته من فريق أو مجلد مشترك أو مشاركة مباشرة أي بيانات جديدة من الفريق أو المجلد المشترك أو السجل. وبالرغم من أنه يتم فك تشفير مفاتيح السجل والمجلد والفريق محلياً للمسؤول خلال النقل، إلا أنه لا يمكن استخدام المفاتيح للوصول إلى بيانات السجل أو المجلد.

يتلقى المسؤول فقط خلال نقل الخزينة مفتاح البيانات المشفر ومفاتيح السجلات المشفرة ومفاتيح المجلدات المشفرة. ويقوم بفك تشفير هذه المفاتيح، وتتم إعادة تشفيرها بواسطة المفتاح العام لخزينة الواجهة. ولا يحصل مطلقاً على وصول إلى بيانات السجل الفعلية. ولا يقوم Keeper بتشفير البيانات المخزنة للعميل مباشرة بمفتاح البيانات، حيث يتم ذلك على الجهاز.

إلغاء إعداد الموظفين إلغاء إعداد الموظفين

الاعتمادات والامتثال

Keeper لا يعرف التهاون بشأن الأمن. Keeper هو الحل الأمني لكلمات المرور ومنصة إدارة الوصول المميز الأكثر أمانًا واعتمادًا واختبارًا وتدقيقًا في العالم. حصل Keeper على اعتماديّ SOC 2 وISO الأقدم في المجال. Keeper حاصل أيضًا على اعتماد ISO 27001 و27017 و27018. Keeper متوافق مع القانون العام لحماية البيانات (GDPR)، ومتوافق مع قانون خصوصية المستهلك في كاليفورنيا (CCPA)، ومتوافق مع قانون منقولية ومساءلة التأمين الصحي (HIPAA)، ومعتمد من FedRAMP وStateRAMP، ومعتمد من PCI DSS ومعتمد من TrustArc للخصوصية.

  • تتكون فرق تطوير برامج Keeper من موظفين بدوام كامل مقرهم في الولايات المتحدة.
  • لا يخزن Keeper كلمات المرور أو بيانات الاعتماد أو الأسرار مثل مفاتيح الوصول في رمز المصدر الخاص به. ونقوم عادة بمسح رمز المصدر بحثاً عن هذه المعلومات.
  • لا يوفر رمز المصدر الخاص بـ Keeper المعلومات المطلوبة للوصول إلى خزينة المستخدم أثناء الاحتفاظ به بشكل خاص في مؤسسة GitHub، حيث يتم تشفير البيانات على مستوى الجهاز. ويتم نشر جزء كبير من هذا الرمز في مستودع GitHub كجزء من منتجات Keeper Commander وKeeper Secrets Manager.
  • لا يدمج Keeper رمز موفر المصادقة متعددة العوامل الخارجي في تطبيقاتنا. ولم يتعرض بائعو Keeper إلى أي عمليات اختراق تتضمن Keeper.
  • لا يوفر Keeper لأي أطراف خارجية الإدارة أو الوصول إلى مراكز بيانات خدمة أمازون ويب الخاصة بنا. حيث تتم كل عمليات الإدارة من قبل موظفي Keeper Security الذين يعملون بدوام كامل وهم مواطنون أمريكيون ومقرهم في الولايات المتحدة.
ISO 27001 SOC2 FedRAMP StateRAMP HIPAA Compliant GDPR Compliant PCI DDS Level 1 TRUSTe Level 1 FIPS 140-3

مُجاز وفقًا لمعيار FIPS 140-3

يستخدم Keeper نماذج تشفير FIPS 140-3 متحقق منها لتلبية المتطلبات الأمنية الصارمة للقطاع الحكومي والعام. وقد تم اعتماد تشفير Keeper من قبل برنامج التحقق من نموذج التشفير (CMVP) NIST وتحقق منه وفقاً إلى معيار FIPS 140 من قبل معامل خارجية معتمدة.

Keeper uses FIPS 140-3 validated encryption that has been issued certificate #4743 under the NIST CMVP.

يمتثل إلى لوائح الاتجار الدولي للأسلحة (ITAR)

يدعم Keeper Security Government Cloud (KSGC) الامتثال إلى لوائح الاتجار الدولي للأسلحة (ITAR). حيث يجب أن تسيطر الشركات التي تخضع إلى لوائح التصدير الخاصة بلوائح الاتجار الدولي للأسلحة على عمليات التصدير غير المقصودة عبر حظر الوصول إلى البيانات المحمية لموطني الولايات المتحدة وعبر حظر الموقع المادي للبيانات المحمية للولايات المتحدة.

تدعم بيئة FedRAMP المعتدلة من KSGC متطلبات لوائح الاتجار الدولي للأسلحة عبر ما يلي:

  • يتم استضافة مخزن بيانات ممتثل بالكامل على GovCloud بخدمة أمازون ويب ويقتصر على الولايات المتحدة.
  • يوفر KSGC تشفير بيانات آمناً خلال النقل والثبات.
  • يسمح الأمن القائم على أسلوب صفر المعرفة ومبدأ انعدام الثقة بالاقتران مع الأذونات الدقيقة للمنظمات بالتأكد من أن يتمكن الموظفون المعتمدون فقط من الوصول إلى البيانات الحساسة.
  • توفر خصائص الإبلاغ بالامتثال القوية سجل مراجعة إلكتروني، يمكن تتبعه لجميع الإجراءات المنفذة والبيانات المدخلة.
  • يتكون فريق نجاح عزل العملاء من مواطنين أمريكيين مدربين خصيصاً على التعامل الآمن للتحكم في البيانات المصدرة والتي تخضع إلى لوائح الاتجار الدولي للأسلحة، من دون أي دعم من خارج الولايات المتحدة.

تم تدقيق بيئة FedRAMP الخاصة بـ Keeper من قبل منظمة تقييم خارجية مستقلة (3PAO) للتحقق من وجود ضوابط ملائمة لدعم برامج امتثال تصدير العملاء ويستمر في أن يخضع للتدقيق بشكل سنوي حسب الاقتضاء لضمان الامتثال.

المزيد من المعلومات حول لوائح الاتجار الدولي للأسلحة (ITAR).

معتمد وفقاً لمتطلبات برنامج FedRAMP

KSGC هو منصة إدارة كلمات المرور وأمن الإنترنت من Keeper Security لمنظمات القطاع العام. KSGC هو موفر FedRAMP معتمد على مستوى الأثر المعتدل، ويستضاف على GovCloud (الولايات المتحدة) بخدمة أمازون ويب. ويمكن العثور على KSGC على متجر FedRAMP

برنامج إدارة المخاطر والتفويض الفيدرالي (FedRAMP) هو برنامج الحكومة الفيدرالية للولايات المتحدة يوفر نهجاً معيارياً للتقييم والتفويض الأمني والرصد المستمر لمنتجات وخدمات السحابة. ويسعى FedRAMP إلى تسريع اتباع حلول حديثة قائمة على السحابة من قبل الكيانات الحكومية، مع التشديد على الأمن وحماية المعلومات الفيدرالية. اعرف المزيد عن FedRAMP.

مفوض من StateRAMP

تم إنشاء StateRAMP بعد حوالي عقد من إنشاء FedRAMP، بهدف التشجيع على اتباع حلول آمنة قائمة على السحابة على مستويات الولاية والحكومة المحلية. عادة الحصول على تفويض StateRAMP يكون عملية تستغرق عامين، وقد تم تبسيطها عبر برنامج التواصل المتبادل بفضل تفويض FedRAMP من Keeper.

امتثال SOC 2

سجلات خزائن العملاء محمية باستخدام ممارسات تحكم داخلية صارمة وتتم مراقبتها عن كثب. ولقد حصل Keeper على اعتماد الامتثال إلى SOC 2 من النوع 2 لأكثر من عشرة أعوام وفقًا لإطار مراقبة تنظيم الخدمات لمؤسسات الخدمات التابع المعهد الأمريكي للمحاسبين القانونيين (AICPA)ويساعد الامتثال لمعيار SOC2 على ضمان الحفاظ على تأمين خزائن المستخدمين من خلال تطبيق أدوات التحكم القياسية على النحو المحدد في إطار مبادئ خدمات الثقة التابع للمعهد الأمريكي للمحاسبين القانونيين.

اعتمادات ISO

Keeper حاصل على اعتمادات ISO 27001 و27017 و27018، التي تغطي نظام إدارة معلومات الأمان من Keeper والبنية التحتية السحابية، التي تدعم منصة Keeper Enterprise. تتضمن اعتمادات ISO التي حصل عليها Keeper إدارة الخزينة الرقمية والخدمات السحابية وتشغيلها، وضوابط الأمان السحابية، وضوابط خصوصية البيانات، وتطوير البرامج والتطبيقات وحماية الموارد الرقمية لكل من الخزينة الرقمية والخدمات السحابية.

يمتثل إلى الجزء 21 من قانون اللوائح الفيدرالية (CFR) التابع لهيئة الغذاء والدواء (FDA)

يمتثل Keeper إلى الباب 21 الجزء 11 من قانون اللوائح الفيدرالية (CFR) والتي تُطبق على العلماء العاملين في بيئات شديدة التنظيم، بما في ذلك الباحثين الذين يجرون تجارب سريرية. وتحدد هذه اللائحة معايير هيئة الغذاء والدواء (FDA) التي يعتبر بموجبها السجلات الإلكترونية والتوقيعات جديرة بالثقة ويمكن الاعتماد عليها وتكافئ السجلات الورقية ذات التوقيعات المكتوبة بخط اليد. وبشكل خاص يجب على العلماء التأكد من امتثال كل البرامج التي يستخدمونها إلى قواعد الباب 21 الجزء 11 من قانون اللوائح الفيدرالية (CFR) بشأن ما يلي:

أداوت تحكم أمنية لتحديد هوية المستخدم – يمتثل Keeper إلى متطلبات الباب 21 الجزء 11 من قانون اللوائح الفيدرالية (CFR) الخاصة بميزات الأمن والتي تحد من وصول المستخدم وامتيازاته، ويشمل ذلك التأكد من امتلاك كل المستخدمين أسماء مستخدمين وكلمات مرور فريدة، والقدرة على اكتشاف الوصول غير المصرح به ومنعه، والقدرة على قفل الحسابات المخترقة.

سجل مراجعة مفصل

خلال عمليات تفتيش إدارة الغذاء والدواء، تطالب المنظمات الباحثين بتوفير مسار تدقيق يضم سجلاً زمنياً مفصلاً لكل العمليات. تسمح ميزات إعداد تقارير الامتثال من Keeper للباحثين بإصدار مسارات تدقيق إلكترونية قابلة للتتبع بسهولة.

التوقيعات الإلكترونية

عندما تطالب وثيقة بوجود توقيع إلكتروني ملزم قانوناً، يُطالب الباب 21 الجزء 11 من قانون اللوائح الفيدرالية (CFR) أن يتم إرفاق التوقيع ببيانات تسجيل دخول وكلمة مرور فريدة أو تحديد الهوية بالمقاييس الحيوية. ويدعم Keeper هذه المتطلبات عبر تمكين الباحثين من ضمان حصول كل المستخدمين على أسماء مستخدمين وكلمات مرور فريدة، وأن يتم تخزينها بأمان في خزينة رقمية لا يستطيع أي شخص الوصول إليها سوى المستخدم فقط.

المزيد من المعلومات حول 21 CFR الجزء 11 متاح هنا.

حماية البيانات الطبية للمرضى

يتوافق برنامج Keeper مع المعايير العالمية لحماية البيانات الطبية بما يشمل، دون تقييد، قانون نقل التأمين الطبي ومسؤوليته (HIPAA) وقانون حماية البيانات (DPA).

الامتثال لقانون منقولية ومساءلة التأمين الصحي واتفاقيات شركاء الأعمال

Keeper هو منصة أمن قائمة على أسلوب صفر المعرفة حاصلة على اعتماد SOC2 وISO 27001 وتمتثل إلى قانون المساءلة وقابلية تنقل التأمين الصحي (HIPAA). ويتم الحفاظ على الالتزام الصارم وأدوات التحكم التي تشمل الخصوصية والسرية والتكامل والإتاحة. ومع بنية الأمن هذه لا يستطيع Keeper فك تشفير أي معلومات أو عرضها أو الوصول إليها بما في ذلك ePHI المخزنة في خزينة Keeper الخاصة بالمستخدم. وللأسباب السابقة الذكر، لا يُعد Keeper شريك عمل على النحو المحدد في قانون المساءلة وقابلية تنقل التأمين الصحي (HIPAA)، وبناء عليه لا يخضع إلى اتفاقية شركاء العمل.

لمعرفة المزيد حول المزايا الإضافية لموفري الرعاية الصحية وشركات التأمين الصحي، يُرجى قراءة هذا الإفصاح الأمني بالكامل وزيارة دليل المؤسسات الخاص بنا.

شهادة نظام تأهيل الخدمات المالية في هولندا

تم اعتماد Keeper Security EMEA Limited بموجب نظام Hellios لتأهيل الخدمات المالية في هولندا (FSQS-NL) الذي يعترف بأعلى معايير الأمان، والجودة، والابتكار في هولندا. ويوضح هذا المعيار الامتثال لهيئة السلوك المالي وهيئة التنظيم التحوطي لضمان مصداقية برنامج Keeper Enterprise للبنوك الكبيرة والمؤسسات المالية.

مرخصة من وزارة التجارة الأمريكية تحت لوائح تنظيم التصدير

Keeper حاصل على اعتماد مكتب الصناعة والأمن التابع لوزارة التجارة الأمريكية بموجب مراقبة تصنيف سلع التصدير رقم 5D992، بالاتساق مع لوائح إدارة الصادرات (EAR).
لمزيد من المعلومات حول لوائح إدارة الصادرات: https://www.bis.doc.gov

مراقبة عن بُعد على مدار الساعة طيلة أيام الأسبوع

يتم مراقبة Keeper على مدار الساعة طوال العام من قبل موظفي DevOps يعملون بدوام كامل وشبكة مراقبة خارجية عالمية لضمات أن يكون موقع الويب وسحابة خزينة الأمن الخاصين بنا متاحين حول العالم.

إذا كان لديك أي أسئلة بشأن هذا الإفصاح الأمني، يُرجى الاتصال بنا.

رسائل البريد الإلكتروني للتصيد الاحتيالي أو رسائل البريد الإلكتروني المخادعة

إذا تلقيت رسالة بريد إلكتروني تزعم أنها مرسلة من Keeper Security وكنت غير متأكد من كونها شرعية، فقد تكون "رسالة بريد إلكتروني احتيالية" حيث تم تزوير أو "تزييف" عنوان البريد الإلكتروني للمرسل. وفي هذه الحالة قد تتضمن رسالة بريد إلكتروني روابط لموقع ويب يبدو مثل KeeperSecurity.com ولكن هذا ليس موقعنا. قد يطلب منك موقع الويب كلمة المرور الرئيسية الخاصة بك على Keeper Security أو يحاول تثبيت برامج غير مرغوب فيها على جهاز الكمبيوتر الخاص بك، في محاولة لسرقة معلوماتك الشخصية أو الوصول إلى جهاز الكمبيوتر الخاص بك. وبعض رسائل البريد الإلكتروني الأخرى تتضمن روابط قد توجهك إلى مواقع ويب أخرى خطيرة بشكل محتمل. وقد تتضمن الرسالة أيضاً مرفقات، والتي عادة ما تتضمن برنامج غير مرغوب فيه يطلق عليه اسم "برنامج ضار". فإذا كنت غير متأكد من رسالة البريد الإلكتروني التي استلمتها في صندوق الوارد لديك، قم بحذفها من دون النقر على أي روابط أو فتح أي مرفقات.

إذا كنت ترغب في الإبلاغ عن رسالة بريد إلكتروني تزعم إنها من Keeper وأنت تعتقد إنها احتيالية أو لديك أي شواغل أمنية أخرى تتضمن شؤون أخرى، فيُرجى الاتصال بنا.

بنية تحتية للاستضافة معتمدة وفقًا لأشد معايير الصناعة صرامة

يعمل موقع الويب وتخزين السحابة في Keeper بنية أساسية للحوسبة على السحابة آمنة تابعة لـAmazon Web Services (AWS). ولقد تم اعتماد بنية السحابة في AWS والتي تستضيف بنية نظام Keeper لتلبية إثباتات وتقارير وشهادات الطرف الثالث التالية:

SOC2 PCI Compliant FIPS 140-3 ISO 27001 FedRAMP StateRAMP

برنامج مكافأة اكتشاف نقاط الضعف والخلل

Keeper Security مخصص لتطوير حل إدارة كلمات المرور والوصول المتميز الأكثر أماناً في السوق. ونحن ملتزمون بحماية الخصوصية والبيانات الشخصية الخاصة بعملائنا. تتمثل مهمة Keeper في بناء منصة الأمن الأكثر أماناً وابتكارا ً في العالم، حيث نعتقد أن تقارير الأخطاء الصادرة من المجتمع العالمي للباحثين في مجال الأمن ضرورية لضمان أمن منتجات وخدمات Keeper.

يجري Keeper اختبارات داخلية وخارجية مكثفة تتضمن اختبارات الاختراق التي تتم من قبل مجموعة NCC وCyberTest بوصول كامل لرمز المصدر. يشغل Keeper برنامج الكشف عن نقاط الضعف بالشراكة مع Bugcrowd. وفي المجمل يفيد هذا المجال بالكامل، وعلاوة على ذلك، يدعم الصالح الاجتماعي.

الإرشادات

تنص سياسة الإفصاح عن أوجه الضعف في Keeper على استثناءات عند العمل مع المخترقين حسني النية، وكذلك ما يمكنك أن تتوقعه منا.

إذا تمت الاختبارات الأمنية وإعداد التقارير الخاصة بها في ضوء المبادئ الإرشادية لهذه السياسة، فنحن:

  • نعتبرها مفوضة وفقاً إلى قانون الاحتيال وإساءة استخدام الكمبيوتر.
  • نعتبرها معفية من قانون الألفية للملكية الرقمية (DMCA) ولن يرفع أي دعوات ضدك لاختراق أي ضوابط أمنية أو تقنية.
  • نعتبرها قانونية ولن نسعى إلى أي أجراء قانوني ضدك يتعلق بهذا البرنامج أو ندعمه.
  • سنعمل معك لفهم المشكلة ولنحلها بسرعة.
  • سنعترف بمساهماتك بشكل علني إذا كنت أول من يبلغ عن المشكلة ونقوم بتغيير رمزاً أو تكويناً استناداً إلى المشكلة.

إذا شعرت بالقلق في أي وقت أو كنت غير واثق من الاختبار بأي شكل يتسق مع المبادئ التوجيهية ونطاق هذه السياسة، فيُرجى التواصل معنا على security@keepersecurity.com قبل المتابعة.

لتشجيع اختبار الأمن حسن النية والإفصاح عن أوجه الضعف المكتشفة، نطلب منك:

  • تجنب اختراق سياسة المستخدم، و/أو الإضرار بتجربة المستخدم، و/أو تعطيل أنظمة الإنتاج أو الشركات، و/أو تدمير البيانات.
  • قم بالأبحاث في نطاق المحدد من قبل برنامج الكشف عن نقاط الضعف من Bugcrowd المربوط أدناه، واحترم الأنظمة والأنشطة التي تقع خارج النطاق.
  • تواصل معنا مباشرة على security@keepersecurity.com إذا صادفت أي بيانات مستخدمين خلال الاختبار.
  • قدم لنا وقت مناسب لتخليل المشكلة المبلغ عنها والتأكد منها وحلها قبل الإفصاح عن أي نقاط ضعف مكتشفة.

يُرجى تقديم التقارير عبر: https://bugcrowd.com/keepersecurity

الشفافية

لا يلتزم Keeper بالأمن فقط؛ بل نحن متعصبون حياله. ولهذا السبب نتيح كل تفاصيل نموذج التشفيرl الخاص بنا للجمهور. ونعتقد أن عملاءنا يستحقون معرفة كل خطوة نتخذها لضمان أمان بياناتهم في مواجهة طبيعة أمن إلكتروني متغيرة دائماً.

يضمن نموذج تشفير Keeper القائم على أسلوب صفر المعرفة ومبدأ انعدام الثقة أنه حتى في أسواء الأحوال، ستكون خزينة Keeper الخاصة بك محمية، وسنستمر في إجراء اختبارات أمنية لنضمن أن نظل أفضل حل لحماية بياناتك الأكثر قيمة.

وثائق المنتج

بوابة توثيق Keeper، تتضمن أدلة المنتج، والمعلومات التقنية، وملاحظات الإصدار، وأدلة المستخدم النهائي، وهي متاحة على هذا الرابط.

ملاحظات إصدار المنتج

لزيادة الشفافية، ينشر Keeper ملاحظات إصدار تفصيلية عبر كل منصة.

حالة النظام

يمكن العثور على حالة النظام في الوقت الفعلي من هنا.

عربى (AE) اتصل بنا