مدیریت دسترسی دقیق و مدیریت داده با امنیت در سطح ردیف – مجله Smashing

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

آن را جدی بگیر

صرف نظر از اینکه درخواست دسترسی در توییتر، بانک یا کتابخانه محلی خود را دارید، شناسایی خود اولین قدم بسیار مهم است. هر نوع دروازه به یک روش قابل اعتماد برای تأیید مشروعیت درخواست دسترسی نیاز دارد.

“سرقت هویت شوخی نیست.”
– دوایت شروت

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

• احراز هویت: عمل تایید هویت کاربر.
• مجوز: اعطای دسترسی کاربر تأیید شده به یک منبع.

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

امنیت در سطح ردیف (RLS)

یک “ردیف”، در این مورد، به ورودی در جدول پایگاه داده اشاره دارد. به عنوان مثال، در یک نوشته ها جدول، یک ردیف تک خواهد بود مقاله، این را بررسی کنید json نمایندگی:

{
    "posts": [
        {
            "id": "article_23495044",
            "title": "User Data Management",
            "content": "<huge blob of text>",
            "publishedAt": "2023-03-28",
            "author": "author_2929292"
        },
        // ...
    ]
}

برای درک RLS، هر کدام object داخل نوشته ها یک “ردیف” است.

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

{
    "posts": {
        "columns": [
            {
                "name": "id",
                "type": "string"
            },
            // ... other primitive types
            // establish relationship with "authors"
            {
                "name": "author",
                "type": "link",
                "link": "authors"
            }
        ]
    }
}

در مثال بالا، ما را تعریف می کنیم type از هر ارزش در ما نوشته ها پایگاه داده و ایجاد یک ارتباط به نویسندگان جدول. بنابراین هر پست دریافت خواهد کرد id از یک نویسنده این یک رابطه یک به چند است: یکی نویسنده می تواند داشته باشد زیاد نوشته ها.

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

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

احراز هویت

زمان راه اندازی یک دستگاه قابل اعتماد و مقرون به صرفه است احراز هویت. مقرون به صرفه است زیرا احراز هویت مجدد کاربر در هر درخواستی غیر سازنده است. و ضریب خطر حملات را افزایش می دهد، بنابراین اجازه دهید درخواست های احراز هویت را به حداقل برسانیم. روشی که اپلیکیشن ما اطلاعات کاربری کاربر را برای استفاده مجدد در یک چرخه حیات تعریف شده ذخیره می کند a نامیده می شود جلسه.

راه های متعددی برای احراز هویت کاربران و مدیریت جلسات وجود دارد. از شما دعوت می‌کنم مقاله اریک بورل در مورد «احراز هویت در وب‌سایت‌ها: یک قیاس بانکی» را بررسی کنید. این یک توضیح عالی و کامل درباره نحوه عملکرد احراز هویت است.

از این لحظه به بعد، بیایید فرض کنیم که دقت لازم را انجام داده ایم: نام کاربری و رمز عبور به طور ایمن ذخیره می شوند، یک ارائه دهنده احراز هویت می تواند به طور قابل اعتماد هویت کاربر ما را تأیید کند و یک عدد را برمی گرداند. session، که یک جسم حامل الف است userId مطابق با ردیف کاربر ما در پایگاه داده.

اتصال نقاط

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

1. احراز هویت
   ارائه دهنده احراز هویت کاربر را انجام می دهد، کتابخانه a ایجاد می کند session، و برنامه آن را به عنوان یک دریافت می کند payload از درخواست auth.
2. درخواست منبع
   کاربر احراز هویت شده درخواست را با resourceId; برنامه می گیرد userId از جانب session.
3. اعطای دسترسی
   تمام منابع را از جدول به منابعی که متعلق به آن هستند فیلتر می کند userId و آن را (در صورت وجود) با resourceId.

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

async function getPostsByAuthor(authorId: string) {
    return sdk.db.posts
        .filter({
            author: authorId
        })
        .getPaginated()
}

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

نتیجه

امیدواریم این مفاهیم شفافیت بیشتری در تعریف مدیریت دسترسی به داده‌های خصوصی و/یا حساس ارائه کرده باشند. توجه به این نکته مهم است که نگرانی‌های امنیتی قبل و پیرامون ذخیره‌سازی این نوع داده‌ها وجود دارد که خارج از محدوده این مقاله بود. به عنوان یک قانون کلی: تا جایی که نیاز دارید ذخیره کنید و فقط میزان دسترسی لازم به داده ها را فراهم کنید. کمترین اطلاعاتی که از طریق سیم عبور می کنند یا توسط برنامه شما ذخیره می شوند، احتمال اینکه برنامه شما هدف یا قربانی حملات یا نشت قرار گیرد کمتر است.

سوالات یا نظرات خود را در بخش نظرات یا در بخش نظرات به من بگویید توییتر.

(Yk)