چه خطراتی با SPO / Onedrive / O365 حساب های کاربری خارجی در دایرکتوری فعال وجود دارد؟

اخیرا ما از O365 / SPO / OneDrive برای کسب و کار به عنوان یک پلتفرم به اشتراک گذاشتن بیش از یک پلت فرم ارائه دهنده پلتفرم قبلی استفاده کرده ایم. من متوجه شده ام که هر بار که یک کاربر به اشتراک گذاشتن محتوا از خارج، کاربر خارجی یک حساب کاربری را در AD خود می گیرد. این غیر مجاز و بدون مجوز است، اما این هنوز یک اعتبار کاربری است که در حال حاضر در دایرکتوری فعال ما است.

چه خطراتی را در رابطه با این حساب کاربری مشاهده می کنید؟

چطوری باید رویه های مقطعی را در نظر گرفت؟

با تشکر

انطباق – چگونه حفظ تعادل بین صداقت و رضایت مشتری در ارزیابی آسیب پذیری

من تعدادی از ارزیابی های آسیب پذیری را انجام داده ام و متوجه روند شده ام. در اولین ارزیابی، مشتریان تحت تأثیر حفره های عظیم امنیتی قرار می گیرند و از آنها سپاسگزارم. در طول ارزیابی های دوم و سوم، آنها احساس نا امیدی می کنند زیرا امیدوار بودند که "گزارش پاک" را به دست آورند که می توانند در بسته بازاریابی خود قرار گیرند و به مشتریان بالقوه خود شگفت زده شوند.

با وجودی که آنها در تلاش برای مقابله با مسائل کار خوبی دارند، مشکل این است که من در کارم بهتر هستم، بنابراین همیشه بیشتر پیدا می کنم. در بالای این همه چیز، امنیت کامل وجود ندارد. من معتقدم که تنها "گزارش تمیز"، جایی است که ارزیاب به اندازه کافی عمیق نگشت. با توجه به ماهیت ارزیابی های آسیب پذیری، من علیه آنها کار می کنم – با این حال، من یک کسب و کار را اداره می کنم و باید یک راه برای همکاری با آنها را پیدا کنم.

من همچنان در آموزش بسیار مفید هستم توسعه دهندگان چگونه برای مقابله با مسائل. واقعیت این است که اغلب تئوری نمی تواند در عمل ترجمه شود. توسعه دهندگان از لحاظ تدابیر شدید و بودجه تنگاتنگ از مدیریت خود می گویند. من صنعت را می دانم، اعتماد به نفس سخت نیست.

این باعث می شود که من وضعیت ناخوشایندی پیدا کنم. مشتریان برای انجام یک ارزیابی با من ترس می کنند زیرا احساس می کنند که آماده نیستند و به اندازه کافی پچ شده اند. آنها (به طور قانونی ترس) از آنچه من پیدا کردم. بعضی حتی به من می گویند "این بار اینقدر عمیق نباشی، خوب؟" و چون نمیخواهم کسب و کارم را از دست بدهم، متوجه میشوم که تواناییهای کامل من را از دست میدهم. نیازی به گفتن نیست، این مهر و موم لاستیک لذت بخش نیست. ممکن است سودآور باشد، اما نه سرگرم کننده است. من نیز نگران این موضوع هستم که این امر منجر به عقب ماندگی خواهد شد، زیرا به ناچار کسی دیگر ارزیابی می کند که چه چیزی انجام داده و حفره های عظیم را بازبینی کرده است. آنها آنها را نتیجه می گیرند که من هیچ نظری ندارم که من انجام می دهم چون من چنین نقص آشکار را از دست دادم. اعتبار همه چیز در این صنعت است، بنابراین این یک خطر بزرگ است.

یک راه حل که من می توانم آن را در نظر بگیرم این است که من همچنان پیدا کردن مشتریان تازه و ماندن از ارزیابی های 2 و 3. پیدا کردن مشتریان تازه چیزی است که به نظر من ناامید کننده و ناکارآمد می باشد. من دوست دارم کسب و کار تکراری را انجام دهم که در طی سالها رابطه من عمیق تر می شود. این روابط طولانی مدت است که من در کسب و کارم لذت می برم. نزدیکی چیزی است که باعث ایجاد مشکل می شود. آیا کسی یک جایگزین پیدا کرده که در آن شما می توانید در معرض هر گونه نقص در پایان هر زمان در حالی که یک مشتری راضی است؟ یا من فقط رویای؟

راه حل دیگری که من سعی کردم محدود کردن دامنه است. اگر من فقط یک بخش کوچکی از پشته را آزمایش کنم، مشتری می تواند آنچه را که دنبال می کنید را دریافت کند: یک گزارش پاک. اما نادر است که آنها با آن موافقند. آنها معمولا همه چیز را آزمایش می کنند. آنها نمی توانند کیک را بخورند و آن را بخورند، اما من با آنها ارتباط برقرار می کنم.

من فکر می کنم پاسخ من به سوال من را می دانم. من فقط تعجب می کنم که آیا چیزی در اینجا از دست رفته یا اگر این تنها راه است و من باید با آن برخورد کنم.

ریسک کسب و کار – API Security – Mutual TLS vs TLS با رمز مشترک.

هر دو می توانند امن باشند، بنابراین حملات بالقوه در اینجا مهم نیست.

تفاوت ها در مدیریت هویت و کلید است.

با PSK (کلید مشترک به اشتراک گذاشته شده) شما فقط یک شناسه کلیدی برای مشتری، یک گواهی با صفات X.500 مانند نام مشترک نیست. بنابراین برای شناسایی هویت شما باید اطلاعات شناخته شده قبلی را به شناسه کلیدی پیوند دهید.

با PSK شما یک کلید مخفی را بین سرویس گیرنده و سرور به اشتراک می گذارید. اما اگر چندین مشتری یا سرور چندگانه وجود داشته باشد، لازم است کلید های بین بسیاری از اشخاص را به اشتراک بگذارید. با گواهی – یا به جای آن، زیرساخت کلید عمومی (PKI یا PKIX) با استفاده از گواهینامه ها ایجاد می شود – شما فقط باید یک راز (یا نسبتا خصوصی) کلید در هر نهاد داشته باشید. کلید عمومی می تواند مورد اعتماد باشد، اگر بخشی از یک گواهینامه در یک زنجیره گواهی باشد، بنابراین کلیدهای عمومی لازم نیست که توزیع شوند.

همانطور که قبلا اشاره کردید، بسیاری از گزینه های دیگر مدیریت کلید برای گواهینامه ها

یکی از معایب استفاده از certs این است که سرور cert معمولا نام سرور را شامل می شود و اتصال ممکن است بر روی میزبان های متفاوت نصب نشده باشد.


برای کسب و کار به کسب و کار من قطعا برای تأیید هویت مشتری / سرور با استفاده از گواهی ها. این رایج ترین و انعطاف پذیر ترین گزینه است. اطمینان حاصل کنید که فقط 19459005 گواهی هایی را که نیاز دارید (و نه همه گواهینامه هایی که به وسیله یک اعتماد معتبر اعتماد دارند) اعتماد کنید.

تزریق sql – چگونه یک شرکت باید به نشت بالقوه PII واکنش نشان دهد؟

من امروز در آب گرم هستم، زیرا زمان زیادی را در دست من در محل کار داشتم و آزمایشهای نفوذ اولیه را انجام دادم. من یک توسعه دهنده نرم افزاری در موسسه مالی هستم، بنابراین قرار دادن کد آسیب پذیر برای حمله SQLi با grep مشکل نبود. دلیل اینکه من در معرض مشکل هستم این بود که با رئیس من تماس نگرفتم، اما در گزارش من کپی شده از CIO و معمار سیستم سربازی. در ایالات متحده، آیا چیزی وجود دارد که به طور رسمی از یک شرکت انتظار می رود که در مورد افشای سوراخ های امنیتی مانند این باشد؟