جلوگیری از تغییرات در فایل mdf

[MRasoul]

سلام
وقتی با vs2013 یه دیتابیسی ایجاد می کنیم، اون رو به صورت فایل mdf ایجاد میکنه، حالا میخواستم بدونم آیا میشه این فایل رو کاری کرد که وقتی به سیستم مشتری انتقال پیدا میکنه، مشتری نتونه بصورت دستی و از خارج از برنامه اطلاعات این فایل رو تغییر بده؟

[SabaSabouhi]

سلام
وقتی با vs2013 یه دیتابیسی ایجاد می کنیم، اون رو به صورت فایل mdf ایجاد میکنه، حالا میخواستم بدونم آیا میشه این فایل رو کاری کرد که وقتی به سیستم مشتری انتقال پیدا میکنه، مشتری نتونه بصورت دستی و از خارج از برنامه اطلاعات این فایل رو تغییر بده؟

سلام
دوست عزیز، این کار امکان‌پذیر نیست.
mdf مربوط هست به فایل‌های استاندارد Data در SqlServer و هر کسی می‌تونه اون رو به سرور خودش Attach کرده و بازش کنه. ( البته اگه ورژن سرورش پایین‌تر نباشه )

صبا صبوحی

[MRasoul]

سلام
دوست عزیز، این کار امکان‌پذیر نیست.
mdf مربوط هست به فایل‌های استاندارد Data در SqlServer و هر کسی می‌تونه اون رو به سرور خودش Attach کرده و بازش کنه. ( البته اگه ورژن سرورش پایین‌تر نباشه )

صبا صبوحی

سلام عزیزم
ینی واقعا هیچ راهی نداره؟
خب اینجور که خیلی بده! مثلا اگر یه رمز رو که نمیخوای کسی ببینه بذاری توی دیتا بیس که اینجور میتونن ببینندش

[SabaSabouhi]

سلام عزیزم
ینی واقعا هیچ راهی نداره؟
خب اینجور که خیلی بده! مثلا اگر یه رمز رو که نمیخوای کسی ببینه بذاری توی دیتا بیس که اینجور میتونن ببینندش

سلام
خوب دوست من، خطای شما تو طرح صورت مساله هست.
کی گفته شما باید رمز رو تو دیتابیس نگه‌داری کنی؟ شما رمز رو Hash کن و به همون صورت تو دیتابیس نگهداری کن.
وقتی کاربر رمزش رو زد، دوباره اون رو Hash کن، اگه دو تا رمز Hash شده با هم یکی بودن، پس رمز درسته.
من قبلاً بجای Hach کردن، CRC رمز رو نگه می‌داشتم، که البته تو منطق کار فرقی نداره. شما باید رمز رو با یک الگوریتم
یکطرفه رمز کنی و تو دیتابیس نگهداری کنی.
به همین راحتی

صبا صبوحی

[golbafan]

سلام میتونید کلیه داده های جداولتون رو بصورت انکریپت شده در جدول بریزید و برای نمایش دادن در نرم افزار خودتون دیکریپت کنید

برای فیلد رمز هش مناسبه (چون فقط مقایسه میکنید) و برای سایر امور باید encrypt استفاده کنید


https://msdn.microsoft.com/en-us/library/bb510663.aspx

[SabaSabouhi]

سلام میتونید کلیه داده های جداولتون رو بصورت انکریپت شده در جدول بریزید و برای نمایش دادن در نرم افزار خودتون دیکریپت کنید

برای فیلد رمز هش مناسبه (چون فقط مقایسه میکنید) و برای سایر امور باید encrypt استفاده کنید


https://msdn.microsoft.com/en-us/library/bb510663.aspx

سلام
یه زمانی تو یه جایی یه کامپیوتر MainFrame به ما معرفی کردن که 60 بیتی بود، بله 60 بیتی و نه 64 بیتی. دلیلش هم این بود که
این کامپیوتر در رده‌ی نظامی بود و سیستمش رو غیر استاندارد طراحی کرده بودن برای مسائل امنیتی. ( مالک این کامپیوتر شرکت نفت بود )
دوست عزیز، قرار نیست همه چیز رو رمز کنی. فقط رمز کاربرا کافیه.
اگه قرار باشه به Admin اعتماد نداشته باشی که دیگه به‌تره کار رو رها کنی بری دنبال یه کار دیگه.
بنا به تجربه این رو می‌گم که تو غالب شرکت‌ها دو نفر خیلی با وسواس انتخاب می‌شن
یکی حسابدار ( یا مدیر مالی ) هست و دیگری Admin ( یا مدیر کامپیوتر یا IT یا هر اسم دیگه‌ای )
این که باید رمز‌ها hash بشن هم دلیلش اینه که هیچ کارمندی نتونه ادعا کنه که یکی دیگه با رمزش وارد شده.

اگر واقعاً سیستم تا این حد حساسه و هیچ نوع اعتمادی هم به Admin نمی‌تونی بکنی دو تا راه حل به ذهن من می‌رسه.
1. استفاده از یه DBMS نامناسب مثل Access که می‌تونی رمزش کنی، اما خوب می‌دونی که برای یه کار متوسط به بالا واقعاً ضعیفه
2. بجای این که با Encrypt و Decrypt نرم‌افراز رو کند کنی و هزینه‌ی تولید و پشتیبانی رو بالا ببری، مکانیزم تشخیص دستکاری ایجاد
کن. روش‌های زیادی رو می‌تونی خودت خلق کنی.
حتا می‌تونی با Trigger جلوی ثبت اطلاعات خارج از برنامه رو بگیری. البته یه کم دردسر داره، اما امکان‌پذیره. من تو یه نرم‌افزار که خیلی
حساس بود، این کار رو کردم. به هیچ عنوان از طریق غیر از برنامه نمی‌شد تو دیتابیس اطلاعات رو دستکاری کرد. همه چیز رو Rollback
می‌کردم. ( کار بی‌خودی بود، اما با توجه به شرایط ویژه پروژه ارزشش رو داشت )

صبا صبوحی

[MRasoul]

سلام
خوب دوست من، خطای شما تو طرح صورت مساله هست.
کی گفته شما باید رمز رو تو دیتابیس نگه‌داری کنی؟ شما رمز رو Hash کن و به همون صورت تو دیتابیس نگهداری کن.
وقتی کاربر رمزش رو زد، دوباره اون رو Hash کن، اگه دو تا رمز Hash شده با هم یکی بودن، پس رمز درسته.
من قبلاً بجای Hach کردن، CRC رمز رو نگه می‌داشتم، که البته تو منطق کار فرقی نداره. شما باید رمز رو با یک الگوریتم
یکطرفه رمز کنی و تو دیتابیس نگهداری کنی.
به همین راحتی

صبا صبوحی

منم رمزهام رو hash کردم، اینجور الان گفتم منظورم این بود که یه چیز مهم رو نخوایی دستی تغییر بدن و حتما از برنامه تغییر کنه باید چکار کرد؟
بازم تشکر

[SabaSabouhi]

منم رمزهام رو hash کردم، اینجور الان گفتم منظورم این بود که یه چیز مهم رو نخوایی دستی تغییر بدن و حتما از برنامه تغییر کنه باید چکار کرد؟
بازم تشکر

سلام
یه راه حل اینه:
توی Trigger می‌تونی userid رو چک کنی. منظور همون userid هست که باهاش به دیتابیس connect شدی.
از یه username خاص استفاده کن، توی Trigger اگه کاربری غیر از این کاربر تغییری اعمال کرد Rollback کن.
رمز این کاربر رو هم فقط تو source برنامه باشه. اگه هم کسی بفهمه که قضیه چیه و دستی رمز اون کاربر
رو عوض کنه برای دستکاری تو اطلاعات، برنامه دیگه نمی‌تونه به دیتابیس وصل بشه و . . .
حداقلش اینه که مشخص می‌شه کسی خواسته دستکاری کنه.

صبا صبوحی

[golbafan]

بجای این که با Encrypt و Decrypt نرم‌افراز رو کند کنی و هزینه‌ی تولید و پشتیبانی رو بالا ببری، مکانیزم تشخیص دستکاری ایجاد
کن. روش‌های زیادی رو می‌تونی خودت خلق کنی

سلام
رمزنگاری دیتابیس الان دیگه یکی از قسمت های معمول sqlserver هست و هیچ هزینه ای نداره (حد اقل کم هزینه تر از ایجاد یک مکانیزم جدیده)

درثانی مواقعی هست که کسی میخواد که مشتری اصلا از ساختار دیتابیس هم بی اطلاع باشه
برای مثال من برای برخی نرم افزارها مثل حسابداری این کار رو میکنم تا شرکت های رقیب نتونن از روش ها و طراحی دیتابیس من مطلع بشن

اینجوری دیگه نیازی به اجرای تریگرهای مختلف و انجام rollback نیست (پس هزینه ها کمتر میشه برادر من)

در ضمن اونچه من گفتم چیز من درآوردی که نبود... بلکه توصیه خود ماکروسافت بود برای کاربا sqlserver اش
توصیه میکنم مطالعه شود:
https://msdn.microsoft.com/en-us/library/ms189586.aspx

این که باید رمز‌ها hash بشن هم دلیلش اینه که هیچ کارمندی نتونه ادعا کنه که یکی دیگه با رمزش وارد شده.

البته بنده هم ذکر کردم که بهتره فیلدهای مقایسه ای (مثل رمز) هش بشن چون برگشت اونها به حالت اول اهمیت نداره
اما وقتی شما مساله ادعا رو مطرح کردید...
عجب!!!

مثلا اگر انکریپت بشه کسی میتونه این ادعا رو بکنه؟؟؟

حتا می‌تونی با Trigger جلوی ثبت اطلاعات خارج از برنامه رو بگیری. البته یه کم دردسر داره، اما امکان‌پذیره. من تو یه نرم‌افزار که خیلی
حساس بود، این کار رو کردم. به هیچ عنوان از طریق غیر از برنامه نمی‌شد تو دیتابیس اطلاعات رو دستکاری کرد. همه چیز رو Rollback
می‌کردم. ( کار بی‌خودی بود، اما با توجه به شرایط ویژه پروژه ارزشش رو داشت )

خدارو شکر قبول دارید روش شما دردسر داره و کار بیخودی بوده

البته کسی هم اگر میخواست میتونست این تریگر رو غیر فعال کنه (کاربر ادمین sql)