با توجه به این مدل، عملکردی که یک سیستم DLP می بایست داشته باشد به صورت نشان دادن واکنش در مقابل جابجایی اطلاعات از منبع می باشد. لذا خواهیم داشت:

مشخص کردن اینکه اطلاعات حساس در بین این حجم اطلاعات کدام دسته می باشند. منظور از اطلاعات حساس اطلاعاتی است که پتانسیل دزدیده شدن را دارند.
منبع می تواند یک نقطه انتهایی، یک فضای ذخیره سازی و یا ترکیبی از هر دو باشد.
عملکرد چیزی است که سیستم DLP در مقابل اطلاعات بلااستفاده یا به اصطلاح in-rest از خود نشان می دهد.

مدل های اشاره شده در واقع یک تعریف کلی از نحوه پیاده سازی واکنش های یک سیستم DLP در شرایط متفاوت بوده است. این مدل ها بر اساس نوع عملکرد سیستم و قوانین امنیتی موجود در یک سیستم DLP کاملا منعطف بوده و قابل تغییر است.

معماری سیستم های DLP

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

کنسول مدیریتی DLP Management Console
عامل نقطه نهایی DLP Endpoint Agent
گذرگاه شبکه DLP Network Gateway
عامل شناسایی اطلاعات Data Discovery Agent or Appliance

با توجه به بخش های ذکر شده در بالا می توانیم معماری کلی زیر را برای یک سیستم DLP ترسیم نماییم:

معماری کلی برای یک سیستم DLP

طبقه بندی اطلاعات و شناسایی آنها

از یک سیستم DLP انتظار می رود که بتواند پاسخ سوالات زیر را بدهد:

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

بررسی اطلاعات یکی از مهمترین توانایی های یک سیستم DLP می باشد. این توانایی از دو بخش تشکیل شده است.

تعریف اطلاعات حساس با دسته بندی اطلاعات
تعریف اطلاعات حساس در شرایط Real-Time

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

یک متن می تواند شامل مفاهیم و ایده های مشخصی است
یک متن می تواند ترکیبی از کلمات می باشد
یک متن می تواند دنباله ای از کارکترهای UTF-8 می باشد
یک متن می تواند دنباله ای از بایت ها می باشد

در سیتسم های DLP ترجیحا استفاده از مدل HTF-8 پیشنهاد می شود. دلایل این انتخاب نیز به شرح زیر می باشد:

همخوانی با تمام زبان ها به خصوص گروه CJK
یک مستند متنی در نهایت با دنباله ای از کارکترهای UTF-8 نرمال سازی می شود

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

انگشت نگاری از مستندات (Document Fingerprinting)
انگشت نگاری از رکوردهای بانک اطلاعاتی (Database Record Fingerprinting)
تطبیق کلیدواژه چندگانه
تطبیق عبارات منظم

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

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

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

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

در یک فضای بزرگ، کاهش عملکرد سیستم بسیار چشمگیر است.
الگوریتم های مقیاس پذیر (Scalable) باید ایجاد شود.

ارزیابی یک الگوریتم طبقه بندی اطلاعات:

می بایست بروی گزارش ها تمرکز کرده و گزارش های صحیح و نا صحیح را بررسی نماییم.
تمرکز بر روی عملکرد سیستم در زمان اجرای الگوریتم.
استقلال در ساختار زبان باید مورد توجه قرار گیرد.

چارچوب قالب اطلاعات را می توان به شکل زیر تجسم کرد:

#security #dlp @unixmens

لایه های امنیتی #security
#service #solution
#solutions


@unixmens

مقاله مدیریت امنیت اطلاعات در سازمان ها #yashar_esmaildokht

آخرین رتبه بندی برترین شرکت های دنیا برای کارکردن.
آمازون با صعود به رتبه 1 جای گوگل را در صدر گرفت.

منبع: https://goo.gl/4gs6nj
#jobs @unixmens

🔹 مصاحبه استخدامی و سوالاتی که بهتر است در ابتدای مصاحبه بپرسید .

کتابی که در مورد openstreetmap نوشتم تقدیم عزیزان , جامعه متن باز نیازمند مشارکت همگان جهت بهبود و توسعه نقشه های باز هست , در این راه به یکدیگر و خودمان کمک کنیم , نقشه باز کاربردهای گسترده و بسیار زیاد دارد , هرگونه انتقاد و پیشنهاد را در مورد کتاب پذیرا هستم
با تشکرات فراوان
یاشار اسمعیل دخت

https://www.dropbox.com/s/sck0kwn3eurnku2/osm.pdf?dl=0
#osm #yashar_esmaildokht @unixmens

شرایط کار در گوگل
#jobs #google @unixmens

تراز سطح آب دریاچه اروميه در تاريخ ۹۷/۵/۱۵ نسبت به روز مشابه در سال قبل یک سانتیمتر، وسعت دریاچه ۱۲/۱۱ کیلومتر مربع و حجم آب موجود در دریاچه ۰/۰۲ميليارد مترمکعب افزایش یافت.

دیده بان محیط زیست
iew.ir

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

@Sabokrou

🔴 @CEITStu

‏Social Mapper یک ابزار متن باز و مفید که به هکرهای قانونی اجازه تست فرایند ردیابی فعالیت کاربران در رسانه های اجتماعی را می دهد
#security #social_media @unixmens

دعوت به همکاری مهندس داده
ارسال رزومه به [email protected]
#jobs #bigdata @unixmens

ویژگی Private Temporary Table

با کمک این ویژگی اوراکل 18c، جدول موقتی در سطح یک session یا transaction ایجاد می شود طوری که session دیگری امکان دسترسی به ان را ندارد همچنین با پایان یافتن session یا transaction، این جدول هم حذف خواهد شد.

فراداده(metadata) مربوط به این جداول معمولا در حافظه ذخیره می شوند(البته امکان ذخیره موقت ان در temporary tablespace هم وجود دارد).

این نوع از جداول باید با پیشوند مشخصی ایجاد شوند که این پیشوند از طریق پارامتر private_temp_table_prefix مشخص می شود:

SQL> show parameter private
NAME VALUE
—---------------------------------- —---------------—
private_temp_table_prefix ORA$PTT_

البته این پیشوند به شرط استفاده از عبارت ORA$ در ابتدای نام و همچنین منحصربفرد بودن ان در بین اسامی اشیاها، قابل تغییر می باشد:

SQL> alter system set private_temp_table_prefix='ORA$usef_' scope=spfile;
System altered.

این نوع از جداول در دو سطح session و transaction قابل تعریف می باشند که به طور پیش فرض(در صورت عدم اعمال نظر در این زمینه)، با پایان یافتن یک transaction، جدول هم حذف خواهد شد.

برای ایجاد جدول در سطح transaction، می توان از عبارت "ON COMMIT DROP DEFINITION" استفاده کرد و استفاده از عبارت "ON COMMIT PRESERVE DEFINITION" هم سبب خواهد شد تا این جدول تا پایان یافتن یک session باقی بماند:

ایجاد جدول در سطح transaction:

SQL> CREATE PRIVATE TEMPORARY TABLE ORA$usef_TBL1 (name varchar2(9),last_name varchar2(9)) ON COMMIT DROP DEFINITION;
Table created.

SQL> insert into ORA$usef_TBL1 values('VAHID','USEFZADEH');
1 row created.

SQL> commit;
Commit complete.

SQL> select * from ORA$usef_TBL1;
ORA-00942: table or view does not exist

ایجاد جدول در سطح session:

SQL> CREATE PRIVATE TEMPORARY TABLE ORA$usef_TBL1 (name varchar2(9),last_name varchar2(9)) ON COMMIT PRESERVE DEFINITION;
Table created.

SQL> insert into ORA$usef_TBL1 values('VAHID','USEFZADEH');
1 row created.

SQL> commit;
Commit complete.

SQL> select * from ORA$usef_TBL1;
NAME LAST_NAME
—------- —-------
VAHID USEFZADEH

ضمن در نظر داشتن این مقدمات، جدول موقت یا private temp tableی را در session شماره یک ایجاد می کنیم:

[oracle@ol7 ~]$ sqlplus "usef/a@PDB"
SQL*Plus: Release 18.0.0.0.0 Production on Wed Apr 11 16:07:37 2018

SQL> CREATE PRIVATE TEMPORARY TABLE ORA$usef_TBL1 (name varchar2(9),last_name varchar2(9)) ON COMMIT PRESERVE DEFINITION;
Table created.
اطلاعاتی را به این جدول اضافه می کنیم:

SQL> insert into ORA$usef_TBL1 values('VAHID','USEFZADEH');
1 row created.

SQL> commit;
Commit complete.

در همین حال، با session جدیدی به این pdb متصل شده و جدولی هم نام با جدول قبلی را در این یوزر ایجاد می کنیم:

select username,sid,serial# from v$session where sid in(SELECT sid FROM v$mystat WHERE ROWNUM = 1);
USERNAME SID SERIAL#
—------------------ —------— —------—
USEF 287 1657

SQL> CREATE PRIVATE TEMPORARY TABLE ORA$usef_TBL1 as select * from v$datafile;
Table created.

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

با توجه به اینکه فراداده مربوط به این نوع از جداول در حافظه ذخیره می شود، پس امکان ایجاد انها در حالت read only هم ممکن می باشد:

SQL> select OPEN_MODE,DATABASE_ROLE from v$database;

OPEN_MODE DATABASE_ROLE
—------------------ —------------—
READ ONLY PHYSICAL STANDBY

SQL> CREATE PRIVATE TEMPORARY TABLE ORA$usef_TBL1 (name varchar2(9),last_name varchar2(9));
Table created.

پ.ن 1: برای مشاهده مشخصات این نوع از جدوال در session جاری، می توان از ویوی USER_PRIVATE_TEMP_TABLES استفاده کرد:

SQL> select SID,SERIAL#,TABLE_NAME from USER_PRIVATE_TEMP_TABLES;
SID SERIAL# TABLE_NAME
—------— —------— —------------------
377 10668 ORA$USEF_TBL1

پ.ن 2: برای مشاهده همه PTTها هم می توان از ویوی DBA_PRIVATE_TEMP_TABLES کمک گرفت.

پ.ن 3: این نوع از جداول بسیاری از قابلیتهای جداول پایدار، نظیر ایجاد ایندکس، پارتیشن بندی، جمع اوری آمار و ... را پشتیبانی نمی کنند.
#oracle @unixmens

مهمترین تفاوت معماری RDBMS با سایر معماریها استفاده از SQL در دستیابی به داده ها می باشد.در زبان غیر رویه ای چگونگی انجام کار تعریف نمی شود، بلکه درخواست توسط یک زبان شبه انگلیسی مطرح می گردد.مثلا در دستور select * from emp که توسط SQL اجرا می گردد، کاربر تنها درخواست خود را مطرح می کند. محل ذخیره شدن جدول emp، چگونگی بازنمودن جدول، چگونگی دستیابی به داده ها و نمایش آن از قبل در این معماری مشخص گردیده است.ولی در یک زبان رویه ای یا procedural تمامی مراحل فراخوانی داده باید برای سیستم مشخص گردد.

زبان غیر رویه ای خود به زبانهای کوچکتر تقسیم می گردد به شرح زیر:
The Data Query Language(DQL)
The Data Manipulation Language(DML)
The Data Definition Language(DDL)
The Data Control Language(DCL)
The Transaction Control Language(TCL)

معماری اوراکل:
هر سیستم RDBMS اوراکل متشکل از دو قسمت زیر می باشد:
1-Database
2-Instance
قسمت Database شامل فایلهای فیزیکی و قسمتهایی منطقی مانند schema بانک اطلاعاتی می باشد.
منظور از Instance روشی است که برای دستیابی به داده ها به کار می رود و شامل پردازشها و حافظه سیستم می باشد.
بانک اطلاعاتی اوراکل شامل یک لایه منطقی و یک لایه فیزیکی است.
لایه فیزیکی شامل فایلهایی است که در دیسک قرار دارند.
لایه منطقی نیز لایه ای است که عناصر آن ،داده ها را به لایه فیزیکی منتقل می کنند.
لایه فیزیکی اوراکل از سه نوع فایل تشکیل شده است که عبارتند از:
1- یک یا چند فایل داده ای یا data file
2- دو یا چند فایل redo log
3- یک یا چند فایل کنترلی یا control file
در زیر شرح هر کدام از این فایلها آورده شده است.