پیشنویس سیاستهای خدمات فناوری اطلاعات
این سند ارسالی تا زمان احراز تصویب و ابلاغ، مبنای تغییر تنظیمات یا الزامات راهنماهای عملی سایت نیست.
متن سند فعلاً فقط به فارسی موجود است. عنوان مادهها را برای دسترسی مستقیم انتخاب کنید.
۲۰ نتیجه
برای چاپ یا ذخیره PDF از گزینه «چاپ» مرورگر استفاده کنید. برای اشتراکگذاری، نشانی صفحه را کپی کنید.
فهرست ۲۰ ماده
ماده ۱ ـ هدف، اصول و جایگاه آییننامه
این آییننامه با هدف ایجاد چارچوب یکپارچه برای ارائه، بهرهبرداری، حفاظت و مدیریت خدمات الکترونیکی و فناوری اطلاعات دانشگاه ایلام تدوین میشود. دامنه آن شامل هویت دیجیتال، حسابهای کاربری، شبکه و اینترنت، شبکه بیسیم، VPN، پست الکترونیکی، احراز هویت مرکزی، تجهیزات کاربران، ثبت رویدادها، حفاظت از اطلاعات و نحوه خاتمه یا محدودسازی دسترسیها است.
جزئیات فنی که ممکن است با تغییر زیرساخت تغییر کنند ــ مانند SSID، نوع EAP، نام سرورهای احراز هویت، روش نصب Authenticator یا Passkey و تنظیمات سیستمعامل ــ در دستورالعملهای اجرایی جداگانه منتشر میشوند و تغییر آنها مستلزم اصلاح متن اصلی این آییننامه نیست.
ماده ۲ ـ دامنه شمول و تعاریف
این آییننامه برای اعضای هیئت علمی، کارکنان، دانشجویان، پژوهشگران، همکاران پژوهشی، استادان مدعو، مهمانان، پیمانکاران، کاربران موقت، مدیران سامانهها و سایر اشخاصی که به خدمات الکترونیکی دانشگاه دسترسی دارند لازمالرعایه است.
برای دیدن همهٔ ستونها، جدول را افقی حرکت دهید. با صفحهکلید: روی جدول بروید و کلیدهای چپ و راست را بزنید.
| اصطلاح | تعریف |
|---|---|
| شناسه یکتا | شناسه شخصی و غیرقابل واگذاری که هویت دیجیتال فرد در دانشگاه را مشخص میکند. |
| SSO | سامانه احراز هویت مرکزی دانشگاه برای ورود یکپارچه به خدمات مجاز. |
| MFA | احراز هویت چندعاملی با استفاده از بیش از یک عامل مستقل، از جمله Authenticator یا Passkey. |
| VPN | خدمت دسترسی امن از راه دور به منابع داخلی یا محدود دانشگاه. |
| BYOD | استفاده از تجهیزات شخصی کاربر برای اتصال به شبکه یا خدمات دانشگاه. |
| دسترسی ممتاز | دسترسی مدیریتی یا فنی با سطح اختیار بالاتر از حساب عادی. |
ماده ۳ ـ حاکمیت، نقشها و مسئولیتها
- مرکز فناوری اطلاعات: مدیریت هویت و حسابها، شبکه، اینترنت، VPN، ایمیل و احراز هویت مرکزی؛ تدوین استانداردهای فنی؛ پایش سرویسها؛ اجرای کنترلهای امنیتی و نگهداری سوابق فنی.
- مالک یا مسئول سامانه: تعیین نیاز کسبوکار، تأیید سطح دسترسی کاربران، بازبینی دسترسیها و اعلام تغییر نقش یا خاتمه نیاز.
- واحد میزبان: مسئول توجیه و مدت دسترسی مهمانان، پیمانکاران و کاربران موقت معرفیشده از سوی آن واحد.
- مدیر سیستم: اجرای کنترلهای فنی، استفاده از حساب مدیریتی شخصی، ثبت تغییرات و رعایت اصل حداقل دسترسی.
- کاربر: حفاظت از عوامل احراز هویت، استفاده مجاز از منابع، رعایت دستورالعملهای امنیتی و گزارش فوری رخدادهای مشکوک.
تصمیم فنی برای مهار فوری تهدید امنیتی از تصمیم اداری یا انضباطی مستقل است. مرکز فناوری اطلاعات میتواند برای حفاظت از دانشگاه دسترسی را بهطور موقت محدود کند، اما رسیدگی اداری یا انضباطی حسب مورد توسط مرجع ذیصلاح انجام میشود.
ماده ۴ ـ هویت دیجیتال و حسابهای کاربری
هر شخص باید برای استفاده از خدمات شخصی دانشگاه از شناسه یکتای متعلق به خود استفاده کند. اشتراکگذاری نام کاربری، گذرواژه، کد یکبارمصرف، Authenticator، Passkey، توکن یا هر عامل احراز هویت با اشخاص دیگر ممنوع است.
ایجاد حساب مشترک یا عمومی فقط در موارد دارای ضرورت فنی یا سازمانی، با مالک مشخص، دامنه دسترسی محدود، سازوکار ثبت استفاده و تأیید مرکز فناوری اطلاعات مجاز است.
اعطای شناسه یکتا بهتنهایی به معنای مجازبودن دسترسی به همه خدمات دانشگاه نیست. هر خدمت باید بر اساس نقش، نیاز و سطح مجوز کاربر فعال شود.
ماده ۵ ـ احراز هویت مرکزی، SSO و احراز هویت چندعاملی
اصل بر آن است که سامانههای دانشگاه برای احراز هویت کاربران از سامانه مرکزی SSO استفاده کنند. ایجاد نام کاربری و گذرواژه مستقل در سامانههای جدید، جز با توجیه فنی و تأیید مرکز فناوری اطلاعات، مجاز نیست.
استفاده از احراز هویت چندعاملی برای کلیه سامانهها و خدمات الکترونیکی دانشگاه الزامی است. سامانهای که بهصورت موقت فاقد امکان فنی اجرای MFA باشد، تنها در چارچوب فرآیند استثنا، با کنترل جبرانی و برنامه زمانبندی مشخص برای انطباق، مجاز به ادامه فعالیت است. سامانهها باید تا حد امکان از احراز هویت مرکزی دانشگاه استفاده کنند و مرحله دوم احراز هویت با یکی از روشهای مورد تأیید دانشگاه، شامل Authenticator یا Passkey، انجام شود.
- بازیابی حساب باید بر اساس فرآیند احراز هویت قابل اتکا انجام شود.
- نشستهای حساس باید دارای زمان انقضای مناسب باشند.
- تغییر یا مفقودی دستگاه Authenticator یا Passkey باید از مسیر رسمی اعلام و عامل قبلی ابطال یا بازثبت شود.
- Authenticator و Passkey روشهای مورد تأیید دانشگاه برای تکمیل احراز هویت چندعاملی هستند؛ جزئیات فنی ثبت، بازیابی و جایگزینی آنها در دستورالعمل اجرایی تعیین میشود.
- سامانهای که از نظر فنی امکان اتصال فوری به SSO یا MFA را ندارد، فقط با ثبت استثنای موقت، کنترل جبرانی، مالک مشخص و برنامه زمانبندی مهاجرت مجاز به ادامه فعالیت است.
ماده ۶ ـ چرخه عمر حسابها و خاتمه دسترسی
چرخه عمر هر حساب از ایجاد تا غیرفعالسازی و حذف باید بر اساس وضعیت رسمی فرد در دانشگاه مدیریت شود. چهار رویداد «قطع دسترسی به سامانهها»، «غیرفعالسازی حساب»، «نگهداری محتوا» و «حذف نهایی» مستقل از یکدیگر هستند.
برای دیدن همهٔ ستونها، جدول را افقی حرکت دهید. با صفحهکلید: روی جدول بروید و کلیدهای چپ و راست را بزنید.
| گروه | مبنای ایجاد | بازبینی | پایان عادی دسترسی |
|---|---|---|---|
| دانشجو | ثبت رسمی و احراز هویت | تغییر وضعیت تحصیلی | پس از فراغت، انصراف یا تغییر وضعیت طبق سیاست مصوب |
| کارمند | شروع رابطه استخدامی | تغییر سمت یا واحد | پایان همکاری |
| عضو هیئت علمی | تأیید استخدام یا همکاری | تغییر وضعیت یا مسئولیت | طبق وضعیت استخدامی و سیاست نگهداری |
| مهمان / پیمانکار | درخواست رسمی واحد میزبان با تاریخ انقضا | تمدید یا تغییر نیاز | خودکار در پایان مدت مصوب |
| همکار پژوهشی | درخواست کتبی عضو هیئت علمی و تأیید مرجع ذیصلاح | تمدید یا تغییر دامنه همکاری | خودکار در پایان مدت مصوب |
حساب مهمان و پیمانکار
درخواست ایجاد حساب موقت باید حداقل شامل مشخصات هویتی، واحد میزبان، هدف دسترسی، خدمات موردنیاز، شماره تماس و تاریخ شروع و پایان اعتبار باشد. حساب موقت بدون تاریخ انقضا نباید ایجاد شود. تمدید مستلزم درخواست و تأیید جدید است.
همکاران پژوهشی اعضای هیئت علمی
اعضای هیئت علمی میتوانند در صورت نیاز پژوهشی، طی درخواست کتبی و با ذکر مشخصات فرد، نوع همکاری، طرح یا واحد پژوهشی مرتبط و مدت موردنیاز، برای همکار پژوهشی خود درخواست ایجاد شناسه یکتای دانشگاهی کنند. پس از تأیید مرجع ذیصلاح، این شناسه میتواند برای مدت مصوب به خدمات مجاز از جمله ایمیل دانشگاهی دسترسی داشته باشد.
مسئولیت اعلام پایان همکاری یا درخواست تمدید بر عهده عضو هیئت علمی درخواستکننده است. در پایان اعتبار، شناسه و خدمات وابسته به آن خودکار غیرفعال میشود؛ مگر آنکه پیش از انقضا تمدید آن تأیید شده باشد.
سیاست غیرفعالسازی ایمیل پس از خروج
برای دیدن همهٔ ستونها، جدول را افقی حرکت دهید. با صفحهکلید: روی جدول بروید و کلیدهای چپ و راست را بزنید.
| گروه | قطع دسترسی حساس | مهلت ایمیل | نگهداری پس از غیرفعالسازی | وضعیت نهایی |
|---|---|---|---|---|
| دانشجوی فارغالتحصیل | پس از تغییر وضعیت و حسب نوع سرویس | ۶ ماه | ۶۰ روز | غیرفعالسازی ایمیل؛ امکان Alumni/alias در صورت تصویب |
| دانشجوی انصرافی | هنگام ثبت قطعی انصراف | ۳۰ روز | ۳۰ روز | غیرفعالسازی و سپس حذف طبق سیاست نگهداری |
| دانشجوی اخراجی / منع دسترسی | فوری یا طبق دستور مرجع ذیصلاح | فوری تا حداکثر ۳۰ روز حسب تصمیم | طبق الزامات اداری/حقوقی | غیرفعالسازی کنترلشده |
| عضو هیئت علمی بازنشسته | پایان دسترسیهای اداری و حساس در پایان مسئولیت | ۱۲ ماه | ۶۰ روز | امکان تمدید یا حساب افتخاری با تأیید |
| عضو هیئت علمی با پایان همکاری | همزمان با پایان همکاری | ۹۰ روز | ۶۰ روز | غیرفعالسازی؛ تمدید فقط با درخواست رسمی |
| کارمند بازنشسته | پایان دسترسیهای اداری و حساس در پایان مسئولیت | ۶ ماه | ۶۰ روز | غیرفعالسازی؛ تمدید موردی با مجوز |
| کارمند با پایان همکاری | همزمان با پایان همکاری | ۳۰ روز | ۳۰ تا ۶۰ روز | غیرفعالسازی؛ امکان قطع فوری در وضعیت امنیتی |
| استاد مدعو / پژوهشگر مهمان | پایان دوره همکاری | ۳۰ روز | ۳۰ روز | غیرفعالسازی خودکار؛ تمدید با درخواست میزبان |
| پیمانکار | فوری در پایان قرارداد | بدون مهلت مگر مجوز کتبی استثنایی | حسب ضرورت قراردادی | غیرفعالسازی خودکار |
| حساب مهمان | در تاریخ انقضای ثبتشده | بدون مهلت اضافی | حداقل لازم برای ممیزی | غیرفعالسازی خودکار |
| حساب مدیریتی | فوری با پایان نقش | مشمول حساب عادی فرد است | لاگها طبق دوره نگهداری | لغو دسترسی ممتاز بدون دوره مهلت |
- برای خروج عادی، در صورت امکان ۳۰ روز و ۷ روز پیش از غیرفعالسازی ایمیل اطلاعرسانی انجام شود.
- تحویل دادهها و مکاتبات سازمانی پیش از خروج باید با هماهنگی مدیر واحد انجام شود؛ انتقال داده محرمانه دانشگاه به حساب شخصی مجاز نیست.
- هر تمدید باید دارای دلیل، تأییدکننده و تاریخ انقضای جدید باشد.
ماده ۷ ـ شبکه سیمی، شبکه بیسیم و اتصال کاربران
استفاده از شبکه دانشگاه باید با حساب فعال و هویت معتبر انجام شود. نفوذ یا تلاش برای دسترسی غیرمجاز، اسکن بدون مجوز، ایجاد اختلال، جعل هویت، توزیع بدافزار، دورزدن کنترلهای امنیتی و راهاندازی سرویس عمومی بدون هماهنگی ممنوع است.
شبکه بیسیم
شبکه بیسیم سازمانی دانشگاه بر پایه احراز هویت کاربر ارائه میشود و کاربر باید از شناسه دانشگاهی خود استفاده کند. پس از احراز هویت موفق، دسترسی متناسب با نقش و مجوز کاربر فراهم میشود. VPN جایگزین اتصال عادی Wi‑Fi نیست و برای دسترسی از راه دور یا منابع محدود استفاده میشود.
مرکز فناوری اطلاعات میتواند از سامانههای کنترل دسترسی شبکه (NAC) برای شناسایی دستگاه، اعمال سیاست امنیتی و محدودسازی تجهیزات مشکوک یا پرخطر استفاده کند.
گواهی و امنیت اتصال
کاربر نباید گواهی سرور ناشناس، منقضی، لغوشده یا نامعتبر را صرفاً برای تکمیل اتصال تأیید کند. مشخصات گواهی و دامنه مورد انتظار باید با اطلاعات منتشرشده در کانال رسمی دانشگاه تطبیق داده شود.
در سرویسهایی که احراز هویت مبتنی بر گواهی دیجیتال بهکار گرفته میشود، فقط گواهیهای صادرشده یا مورد تأیید دانشگاه معتبر هستند. کلید خصوصی گواهی باید محرمانه بماند و در اختیار شخص دیگر قرار نگیرد. در صورت مفقودی دستگاه، افشای کلید یا پایان اعتبار حساب، گواهی مربوط باید بدون تأخیر ابطال یا جایگزین شود. جزئیات صدور، نصب، تمدید و ابطال گواهی در دستورالعمل فنی مرکز فناوری اطلاعات تعیین میشود.
پشتیبانی Wi‑Fi
در درخواست پشتیبانی، نوع دستگاه، سیستمعامل، محل، زمان تقریبی و شرح خطا باید ارائه شود. ارسال گذرواژه، کلید خصوصی، فایل PFX/P12 یا رمز گواهی در تیکت، ایمیل یا پیامرسان ممنوع است و کارشناس پشتیبانی نیز نباید چنین اطلاعاتی را مطالبه کند.
ماده ۸ ـ مصرف اینترنت و مدیریت پهنای باند
در حال حاضر برای کاربران دانشگاه سقف مشخصی از نظر حجم مصرف اینترنت تعیین نشده است و استفاده از خدمات شبکه بر مبنای اصل استفاده متعارف و منصفانه انجام میشود. فعالیتهای آموزشی، پژوهشی و اداری دانشگاه در تخصیص منابع شبکه اولویت دارند.
چنانچه میزان یا الگوی مصرف یک کاربر، دستگاه یا سرویس موجب اختلال در عملکرد شبکه، کاهش محسوس کیفیت خدمات، اشغال نامتعارف پهنای باند، ایجاد مخاطره امنیتی یا اثر منفی بر دسترسی سایر کاربران شود، مرکز فناوری اطلاعات میتواند بهصورت موقت و متناسب، پهنای باند یا برخی دسترسیهای آن را محدود کند.
محدودیت باید تا حد امکان متناسب با میزان اثرگذاری بوده و صرفاً تا زمان رفع عامل اختلال ادامه یابد. در صورت تکرار، موضوع میتواند برای تصمیم مقتضی به مرجع ذیصلاح ارجاع شود.
ماده ۹ ـ VPN و دسترسی از راه دور
VPN دانشگاه برای دسترسی مجاز از خارج شبکه دانشگاه به منابع داخلی یا محدود ارائه میشود و استفاده از آن منوط به احراز هویت قوی است.
- هر کاربر فقط با شناسه شخصی خود مجاز به اتصال است.
- Authenticator یا Passkey باید متعلق به همان کاربر و تحت کنترل او باشد.
- اشتراک حساب، عامل احراز هویت یا استفاده از عامل متعلق به شخص دیگر ممنوع است.
- در صورت گمشدن، سرقت یا تعویض دستگاه احراز هویت، کاربر باید موضوع را بدون تأخیر اعلام کند.
- دسترسیهای ویژه VPN باید دارای مالک، محدوده دسترسی، توجیه نیاز و تاریخ بازبینی باشند.
- VPN مهمان، پژوهشگر مهمان و پیمانکار باید تاریخ انقضا و تأیید واحد میزبان داشته باشد.
- در پایان همکاری، تغییر نقش یا رخداد امنیتی، دسترسی VPN میتواند مستقل از ایمیل فوراً غیرفعال شود.
ماده ۱۰ ـ پست الکترونیکی دانشگاهی
پست الکترونیکی دانشگاهی برای ارتباطات آموزشی، پژوهشی، اداری و سایر فعالیتهای رسمی در اختیار کاربران واجد شرایط قرار میگیرد.
- ارسال هرزنامه، فیشینگ، جعل فرستنده، انتشار بدافزار و ارسال انبوه بدون مجوز ممنوع است.
- ارسال دادههای محرمانه باید متناسب با سطح طبقهبندی و کنترلهای امنیتی مصوب انجام شود.
- Forward خودکار ایمیل دانشگاهی به سرویسهای شخصی مجاز است. مسئولیت صحت نشانی مقصد، حفاظت از محرمانگی اطلاعات و رعایت الزامات امنیتی بر عهده صاحب حساب است. ارسال یا انتقال خودکار اطلاعات محرمانه یا بسیار حساس به سرویسهای شخصی، مگر با مجوز صریح دانشگاه، مجاز نیست.
- صندوقهای مشترک و سازمانی باید مالک و مسئول پاسخگویی مشخص داشته باشند.
- مدت فعالبودن ایمیل پس از خروج مطابق جدول چرخه عمر حسابها تعیین میشود و به معنای ادامه VPN یا دسترسی به سامانههای اداری نیست.
استفاده از آدرس رسمی دانشگاه برای فعالیتهای شخصی تجاری، جعل عنوان سازمانی یا ایجاد برداشت نادرست از موضع رسمی دانشگاه مجاز نیست.
ماده ۱۱ ـ تجهیزات شخصی، تجهیزات دانشگاهی و BYOD
اتصال لپتاپ، تلفن همراه و سایر تجهیزات شخصی به شبکه دانشگاه مشروط به رعایت حداقل الزامات امنیتی است؛ از جمله سیستمعامل پشتیبانیشده، بهروزرسانی امنیتی، قفل صفحه و نداشتن آلودگی شناختهشده.
مرکز فناوری اطلاعات میتواند در حد نیاز امنیتی و عملیاتی، اطلاعات فنی لازم برای کنترل اتصال را ثبت و پردازش کند. دستگاه مشکوک، آلوده یا دارای رفتار مخرب میتواند تا زمان رفع مشکل از شبکه جدا یا قرنطینه شود.
کاربر نباید برای رفع مشکل اتصال، کنترلهای امنیتی سیستمعامل، اعتبارسنجی گواهی یا سایر سازوکارهای حفاظتی را خارج از دستورالعمل رسمی غیرفعال کند.
ماده ۱۲ ـ طبقهبندی و حفاظت از اطلاعات
برای دیدن همهٔ ستونها، جدول را افقی حرکت دهید. با صفحهکلید: روی جدول بروید و کلیدهای چپ و راست را بزنید.
| سطح | نمونه | قاعده کلی |
|---|---|---|
| عمومی | اطلاعات رسمی منتشرشده | قابل انتشار عمومی |
| داخلی | مکاتبات و اطلاعات عملیاتی عادی | مصرف دروندانشگاهی و دسترسی متناسب با وظیفه |
| محرمانه | پرونده دانشجو یا کارمند، داده پژوهشی محدود | دسترسی نیازمحور، کنترلشده و ثبتپذیر |
| بسیار حساس | گذرواژهها، کلیدهای امنیتی، داده مالی حساس و اطلاعات امنیتی | حداقل دسترسی، حفاظت قوی، رمزنگاری متناسب و ثبت رویداد |
مالک داده یا سامانه باید سطح طبقهبندی مناسب را تعیین کند و کاربران موظفاند شیوه ذخیرهسازی، انتقال و اشتراک اطلاعات را با آن سطح هماهنگ کنند.
ماده ۱۳ ـ ثبت رویدادها، پایش و حریم خصوصی
ثبت لاگ و پایش فنی صرفاً برای اهداف مشروع از جمله امنیت، پایداری، عیبیابی، مدیریت ظرفیت، ممیزی و پاسخگویی قانونی یا اداری انجام میشود. مدت نگهداری عادی لاگهای شبکه، VPN، SSO و سرویس ایمیل سه ماه است. منظور از لاگ سرویس ایمیل، فرادادهها و رویدادهای فنی مرتبط با سرویس است و این مدت به محتوای صندوق پستی کاربران تسری ندارد. در صورت وقوع رخداد امنیتی، درخواست قانونی، پرونده اداری یا ضرورت ممیزی، لاگهای مرتبط میتوانند تا پایان رسیدگی و مطابق مجوز مربوط برای مدت طولانیتر نگهداری شوند.
- نوع داده ثبتشده و اشخاص مجاز به مشاهده باید در دستورالعمل یا جدول نگهداری مشخص شود؛ دوره نگهداری عادی لاگها سه ماه است. نگهداری محتوای ایمیل و فایلهای کاربران تابع جدول چرخه عمر حساب و سیاست نگهداری محتوای مربوط است.
- دسترسی به محتوای کاربران فقط در حدود اختیار قانونی و اداری و بر اساس ضرورت انجام میشود.
- لاگها نباید برای مقاصد نامرتبط با هدف جمعآوری مورد استفاده قرار گیرند.
- دسترسی به لاگهای حساس باید محدود، ثبتشده و قابل ممیزی باشد.
ماده ۱۴ ـ حسابهای مدیریتی و دسترسی ممتاز
حساب مدیریتی باید از حساب عادی فرد جدا باشد و صرفاً برای انجام وظایف مدیریتی استفاده شود. اصل حداقل دسترسی و تفکیک وظایف باید رعایت شود.
- استفاده از حساب مدیریتی مشترک، جز در حسابهای اضطراری کنترلشده، ممنوع است.
- دسترسی ممتاز باید مالک، دلیل، دامنه و دوره بازبینی مشخص داشته باشد.
- فعالیتهای حساس مدیریتی باید تا حد امکان ثبت و قابل ممیزی باشند.
- با پایان نقش مدیریتی، دسترسی ممتاز باید بدون دوره مهلت لغو شود.
ماده ۱۵ ـ مدیریت رخدادهای امنیتی و پشتیبانی
کاربران موظفاند رخدادهایی مانند سرقت یا افشای گذرواژه، فیشینگ، فعالیت غیرعادی حساب، آلودگی بدافزاری، گمشدن دستگاه، هشدار گواهی مشکوک و دسترسی ناخواسته را بدون تأخیر از مسیر رسمی گزارش کنند.
مرکز فناوری اطلاعات میتواند برای مهار تهدید، حساب، دستگاه، VPN یا بخشی از دسترسی را موقتاً محدود کند. پس از رفع مخاطره، بازگردانی دسترسی مطابق فرآیند مصوب انجام میشود.
در تیکت یا درخواست پشتیبانی نباید گذرواژه، کد یکبارمصرف، کلید خصوصی یا فایلهای حاوی اسرار احراز هویت درج شود.
ماده ۱۶ ـ خدمات ابری، نرمافزارهای ثالث و هوش مصنوعی
اتصال نرمافزار یا سرویس ثالث به ایمیل، SSO، APIها یا دادههای دانشگاه باید پیش از بهرهبرداری از نظر امنیت، سطح دسترسی و حریم خصوصی بررسی شود.
ورود اطلاعات محرمانه یا بسیار حساس، اطلاعات هویتی و اداری حفاظتشده، گذرواژهها، کلیدها و دادههای پژوهشی محدود به سرویسهای عمومی هوش مصنوعی یا سرویسهای ثالث بدون مجوز دانشگاه ممنوع است.
استفاده از ابزارهای هوش مصنوعی برای امور دانشگاهی باید بهگونهای باشد که مسئولیت صحت، محرمانگی و تصمیم نهایی همچنان بر عهده کاربر یا واحد مسئول باقی بماند.
ماده ۱۷ ـ استفاده مجاز، تخلفات و اقدامات اصلاحی
استفاده از خدمات دانشگاه باید با مأموریت آموزشی، پژوهشی و اداری دانشگاه سازگار باشد. استفاده شخصی محدود که موجب هزینه قابل توجه، اختلال، مخاطره امنیتی یا تعارض با وظایف دانشگاهی نشود میتواند قابل قبول باشد.
نمونههای تخلف شامل دسترسی غیرمجاز، جعل هویت، دورزدن کنترلهای امنیتی، انتشار بدافزار، بهرهبرداری نامتعارف از منابع، سوءاستفاده از حساب دیگران و نقض حقوق اشخاص یا مقررات دانشگاه است.
اقدامات میتواند متناسب با شدت موضوع شامل هشدار، محدودسازی فنی، تعلیق موقت دسترسی و ارجاع به مرجع اداری یا انضباطی ذیصلاح باشد.
ماده ۱۸ ـ نگهداری، بازیابی و حذف اطلاعات
برای ایمیل، فایلها، نسخههای پشتیبان و حسابهای غیرفعال باید جدول نگهداری اطلاعات (Retention Matrix) تدوین و نگهداری شود. مدت نگهداری عادی لاگهای شبکه، VPN، SSO و ایمیل سه ماه است. جدول نگهداری باید برای سایر انواع داده، مدت نگهداری، مبنای آن، مالک داده و شیوه حذف نهایی را مشخص کند.
نگهداری محتوا پس از غیرفعالسازی حساب صرفاً به معنای نگهداری فنی برای دوره مقرر است و مجوز استفاده عادی کاربر از حساب محسوب نمیشود. حذف نهایی پس از پایان مهلت مصوب باید با روش مناسب و قابل کنترل انجام شود.
ماده ۱۹ ـ استثناهای فنی و پژوهشی
نیازهای خاص پژوهشی، آزمایشگاهی یا فنی که با قواعد عمومی سازگار نیستند باید از طریق فرآیند رسمی استثنا مدیریت شوند. هر استثنا باید دارای درخواستکننده، مالک، دلیل، دامنه، کنترل جبرانی، تاریخ شروع و تاریخ انقضا باشد.
استثنا نباید دائمی فرض شود و باید در پایان مدت یا هنگام تغییر شرایط بازبینی شود.
ماده ۲۰ ـ تصویب، لازمالاجرا شدن و بازنگری
این آییننامه پس از تصویب و ابلاغ توسط مرجع ذیصلاح دانشگاه لازمالاجرا است و کلیه واحدها، مدیران سامانهها و کاربران مشمول موظف به رعایت آن هستند.
مرکز فناوری اطلاعات موظف است دستورالعملهای فنی لازم برای اجرای این آییننامه، از جمله دستورالعملهای Wi‑Fi، VPN و MFA، ایمیل، SSO، مدیریت حساب و پاسخگویی به رخداد را تهیه و بهروز نگه دارد. تغییرات صرفاً فنی که مغایر مفاد این آییننامه نباشند، نیازمند اصلاح متن اصلی آییننامه نیستند.
این آییننامه حداقل سالی یکبار و نیز در صورت تغییر اساسی در زیرساخت، الزامات قانونی، مدل احراز هویت یا مخاطرات امنیتی بازنگری میشود. هر تغییر در سیاستهای مصوب، از جمله چرخه عمر حساب و ایمیل، دامنه MFA، تعداد دستگاه مجاز، سیاست مصرف اینترنت و مدت نگهداری لاگها، باید از مسیر تصویب و ابلاغ دانشگاه انجام شود.
