جاوا میں سیکیورٹی: بہترین طریقے

سرور ایپلی کیشنز میں، سب سے اہم اشارے میں سے ایک سیکورٹی ہے. یہ غیر فعال تقاضوں کی اقسام میں سے ایک ہے ۔ سیکورٹی کے بہت سے اجزاء ہوتے ہیں۔ بلاشبہ، ان تمام حفاظتی اصولوں اور اعمال کا مکمل احاطہ کرنے کے لیے جو معلوم ہیں، آپ کو ایک سے زیادہ مضمون لکھنے کی ضرورت ہے، لہذا آئیے سب سے اہم پر توجہ مرکوز کریں۔ ایک شخص جو اس موضوع میں اچھی طرح سے مہارت رکھتا ہے، تمام عمل کو ترتیب دینے کے قابل ہو گا اور اس بات کو یقینی بنائے گا کہ وہ نئے سیکورٹی سوراخ نہیں بنائے گا، کسی بھی ٹیم میں ضرورت ہو گی. یقینا، آپ کو یہ نہیں سوچنا چاہیے کہ اگر آپ ان طریقوں پر عمل کرتے ہیں، تو درخواست مکمل طور پر محفوظ رہے گی۔ نہیں! لیکن یہ یقینی طور پر ان کے ساتھ زیادہ محفوظ ہوگا۔ جاؤ.

1. جاوا زبان کی سطح پر سیکورٹی فراہم کریں۔

سب سے پہلے، جاوا میں سیکیورٹی زبان کی خصوصیت کی سطح سے شروع ہوتی ہے۔ اگر رسائی میں ترمیم کرنے والے نہ ہوتے تو ہم یہی کرتے؟... انارکی، کم نہیں۔ ایک پروگرامنگ لینگویج ہمیں محفوظ کوڈ لکھنے اور بہت سی مضمر حفاظتی خصوصیات سے فائدہ اٹھانے میں مدد کرتی ہے:

1. مضبوط ٹائپنگ۔ جاوا ایک مستحکم طور پر ٹائپ شدہ زبان ہے جو چلانے کے وقت ٹائپ کی غلطیوں کا پتہ لگانے کی صلاحیت فراہم کرتی ہے۔
2. ترمیم کرنے والوں تک رسائی۔ ان کی بدولت، ہم اپنی ضرورت کے مطابق کلاسز، طریقوں اور کلاس فیلڈز تک رسائی کو ترتیب دے سکتے ہیں۔
3. خودکار میموری کا انتظام۔ اس مقصد کے لیے، ہمارے پاس (جاواسٹس؛)) کوڑا جمع کرنے والا ہے، جو آپ کو دستی ترتیب سے آزاد کرتا ہے۔ ہاں، کبھی کبھی مسائل پیدا ہوتے ہیں۔
4. بائٹ کوڈ چیکنگ: جاوا بائیک کوڈ پر مرتب کرتا ہے، جسے چلانے سے پہلے رن ٹائم کے ذریعے چیک کیا جاتا ہے۔

دیگر چیزوں کے علاوہ، سیکورٹی پر اوریکل کی جانب سے سفارشات بھی موجود ہیں ۔ یقینا، یہ "اعلی انداز" میں نہیں لکھا گیا ہے اور آپ اسے پڑھتے ہوئے کئی بار سو سکتے ہیں، لیکن یہ اس کے قابل ہے۔ ایک خاص طور پر اہم دستاویز Java SE کے لیے Secure Coding Guidelines ہے ، جو محفوظ کوڈ لکھنے کے طریقے کے بارے میں تجاویز فراہم کرتی ہے۔ اس دستاویز میں بہت ساری مفید معلومات ہیں۔ اگر ممکن ہو تو، یہ یقینی طور پر پڑھنے کے قابل ہے. اس مواد میں دلچسپی پیدا کرنے کے لیے، یہاں کچھ دلچسپ تجاویز ہیں:

1. محفوظ حساس کلاسوں کو سیریلائز کرنے سے گریز کریں۔ اس صورت میں، آپ سیریلائزڈ فائل سے کلاس انٹرفیس حاصل کر سکتے ہیں، اس ڈیٹا کا ذکر نہ کریں جو سیریلائز ہو رہا ہے۔
2. متغیر ڈیٹا کلاسوں سے بچنے کی کوشش کریں۔ یہ ناقابل تغیر کلاسز کے تمام فوائد فراہم کرتا ہے (جیسے تھریڈ سیفٹی)۔ اگر کوئی متغیر آبجیکٹ ہے، تو یہ غیر متوقع سلوک کا باعث بن سکتا ہے۔
3. واپس آنے والی تغیر پذیر اشیاء کی کاپیاں بنائیں۔ اگر کوئی طریقہ کسی اندرونی تغیر پذیر آبجیکٹ کا حوالہ دیتا ہے، تو کلائنٹ کوڈ آبجیکٹ کی اندرونی حالت کو تبدیل کر سکتا ہے۔
4. اور اسی طرح…

عام طور پر، Java SE کے لیے محفوظ کوڈنگ کے رہنما خطوط میں جاوا میں صحیح اور محفوظ طریقے سے کوڈ لکھنے کے طریقے کے بارے میں تجاویز اور چالوں کا ایک مجموعہ شامل ہے۔

2. ایس کیو ایل انجیکشن کے خطرے کو ختم کریں۔

انوکھی کمزوری اس کی انفرادیت اس حقیقت میں مضمر ہے کہ یہ سب سے مشہور اور سب سے عام کمزوریوں میں سے ایک ہے۔ اگر آپ سیکیورٹی کے معاملے میں دلچسپی نہیں رکھتے ہیں، تو آپ کو اس کے بارے میں معلوم نہیں ہوگا۔ ایس کیو ایل انجیکشن کیا ہے؟ یہ اضافی ایس کیو ایل کوڈ انجیکشن لگا کر ڈیٹا بیس پر حملہ ہے جہاں اس کی توقع نہیں ہے۔ ہم کہتے ہیں کہ ہمارے پاس ایک طریقہ ہے جو ڈیٹا بیس سے استفسار کرنے کے لیے کچھ پیرامیٹر لیتا ہے۔ مثال کے طور پر، صارف نام۔ کمزوری کے ساتھ کوڈ کچھ اس طرح نظر آئے گا:

// Метод достает из базы данных всех пользователей с определенным именем
public List<User> findByFirstName(String firstName) throws SQLException {
   // Создается связь с базой данных
   Connection connection = DriverManager.getConnection(DB_URL, USER, PASS);

   // Пишем sql request в базу данных с нашим firstName
   String query = "SELECT * FROM USERS WHERE firstName = " + firstName;

   // выполняем request
   Statement statement = connection.createStatement();
   ResultSet result = statement.executeQuery(query);

   // при помощи mapToUsers переводит ResultSet в коллекцию юзеров.
   return mapToUsers(result);
}

private List<User> mapToUsers(ResultSet resultSet) {
   //переводит в коллекцию юзеров
}

اس مثال میں، sql استفسار ایک الگ لائن میں پہلے سے تیار کیا جاتا ہے۔ ایسا لگتا ہے کہ مسئلہ کیا ہے، ٹھیک ہے؟ شاید مسئلہ یہ ہے کہ اسے استعمال کرنا بہتر ہوگا String.format؟ نہیں؟ پھر کیا؟ آئیے خود کو ٹیسٹر کی جگہ پر رکھیں اور سوچیں کہ قدر میں کیا کیا جا سکتا ہے firstName۔ مثال کے طور پر:

1. آپ وہ پاس کر سکتے ہیں جس کی توقع ہے - صارف نام۔ پھر ڈیٹا بیس تمام صارفین کو اس نام کے ساتھ واپس کر دے گا۔
2. آپ ایک خالی سٹرنگ پاس کر سکتے ہیں: پھر تمام صارفین کو واپس کر دیا جائے گا۔
3. یا آپ درج ذیل کو پاس کر سکتے ہیں: ''''; ڈراپ ٹیبل استعمال کنندگان؛"۔ اور یہاں بڑے مسائل ہوں گے۔ یہ استفسار ٹیبل کو ڈیٹا بیس سے ہٹا دے گا۔ تمام ڈیٹا کے ساتھ۔ ہر کوئی

کیا آپ تصور کر سکتے ہیں کہ اس سے کیا مسائل پیدا ہو سکتے ہیں؟ پھر آپ جو چاہیں لکھ سکتے ہیں۔ آپ تمام صارفین کے نام تبدیل کر سکتے ہیں، آپ ان کے پتے حذف کر سکتے ہیں۔ تخریب کاری کا دائرہ وسیع ہے۔ اس سے بچنے کے لیے، آپ کو ریڈی میڈ استفسار کو انجیکشن لگانا بند کرنا ہوگا اور اس کے بجائے اسے پیرامیٹرز کا استعمال کرکے بنانا ہوگا۔ ڈیٹا بیس سے استفسار کرنے کا یہ واحد طریقہ ہونا چاہیے۔ اس طرح آپ اس کمزوری کو ختم کر سکتے ہیں۔ مثال:

// Метод достает из базы данных всех пользователей с определенным именем
public List<User> findByFirstName(String firstName) throws SQLException {
   // Создается связь с базой данных
   Connection connection = DriverManager.getConnection(DB_URL, USER, PASS);

   // Создаем параметризированный request.
   String query = "SELECT * FROM USERS WHERE firstName = ?";

   // Создаем подготовленный стейтмент с параметризованным requestом
   PreparedStatement statement = connection.prepareStatement(query);

   // Передаем meaning параметра
   statement.setString(1, firstName);

   // выполняем request
   ResultSet result = statement.executeQuery(query);

   // при помощи mapToUsers переводим ResultSet в коллекцию юзеров.
   return mapToUsers(result);
}

private List<User> mapToUsers(ResultSet resultSet) {
   //переводим в коллекцию юзеров
}

اس طرح، اس خطرے سے بچا جاتا ہے. ان لوگوں کے لیے جو اس مضمون سے زیادہ گہرائی میں جانا چاہتے ہیں، یہاں ایک بہترین مثال ہے ۔ اگر آپ اس حصے کو سمجھتے ہیں تو آپ کو کیسے پتہ چلے گا؟ اگر نیچے کا لطیفہ واضح ہو گیا تو یہ یقینی علامت ہے کہ کمزوری کا جوہر واضح ہے :D

3. اسکین کریں اور انحصار کو اپ ڈیٹ رکھیں

اس کا کیا مطلب ہے؟ ان لوگوں کے لیے جو نہیں جانتے کہ انحصار کیا ہے، میں وضاحت کروں گا: یہ کوڈ کے ساتھ ایک جار آرکائیو ہے جو کسی اور کے حل کو دوبارہ استعمال کرنے کے لیے خودکار بلڈ سسٹم (Maven، Gradle، Ant) کا استعمال کرتے ہوئے کسی پروجیکٹ سے منسلک ہوتا ہے۔ مثال کے طور پر، پروجیکٹ لومبوک ، جو رن ٹائم پر ہمارے لیے گیٹرز، سیٹرز وغیرہ تیار کرتا ہے۔ اور اگر ہم بڑی ایپلی کیشنز کے بارے میں بات کرتے ہیں، تو وہ بہت سے مختلف انحصار استعمال کرتے ہیں۔ کچھ عبوری ہیں (یعنی ہر انحصار کا اپنا انحصار ہوسکتا ہے، وغیرہ)۔ لہذا، حملہ آور اوپن سورس کے انحصار پر تیزی سے توجہ دے رہے ہیں، کیونکہ وہ باقاعدگی سے استعمال ہوتے ہیں اور بہت سے کلائنٹس کے لیے مسائل پیدا کر سکتے ہیں۔ یہ یقینی بنانا ضروری ہے کہ پورے انحصار کے درخت میں کوئی معلوم کمزوریاں نہیں ہیں (جو بالکل ویسا ہی لگتا ہے)۔ اور ایسا کرنے کے کئی طریقے ہیں۔

نگرانی کے لیے Snyk استعمال کریں۔

Snyk ٹول پراجیکٹ کے تمام انحصارات اور معلوم کمزوریوں کی جانچ کرتا ہے۔ وہاں آپ GitHub کے ذریعے اپنے پروجیکٹس کو رجسٹر اور امپورٹ کر سکتے ہیں، مثال کے طور پر۔ اس کے علاوہ، جیسا کہ آپ اوپر کی تصویر سے دیکھ سکتے ہیں، اگر کسی نئے ورژن کے پاس اس خطرے کا کوئی حل ہے، تو Snyk ایسا کرنے کی پیشکش کرے گا اور ایک Pull-Request تخلیق کرے گا۔ اسے اوپن سورس پروجیکٹس کے لیے مفت استعمال کیا جا سکتا ہے۔ پروجیکٹس کو کچھ فریکوئنسی پر اسکین کیا جائے گا: ہفتے میں ایک بار، مہینے میں ایک بار۔ میں نے اپنے تمام عوامی ذخیروں کو Snyk اسکین میں رجسٹر کیا اور شامل کیا (اس میں کوئی خطرناک بات نہیں ہے: وہ پہلے ہی سب کے لیے کھلے ہیں)۔ اس کے بعد، Snyk نے اسکین کا نتیجہ دکھایا: اور تھوڑی دیر کے بعد، Snyk-bot نے ایسے پروجیکٹس میں کئی Pull-Requests تیار کیں جہاں انحصار کو اپ ڈیٹ کرنے کی ضرورت ہے: اور یہاں ایک اور ہے: تو یہ کمزوریوں کو تلاش کرنے اور اپ ڈیٹ کرنے کی نگرانی کے لیے ایک بہترین ٹول ہے۔ نئے ورژن.

GitHub سیکیورٹی لیب استعمال کریں۔

جو لوگ GitHub پر کام کرتے ہیں وہ اپنے بلٹ ان ٹولز سے بھی فائدہ اٹھا سکتے ہیں۔ آپ اس نقطہ نظر کے بارے میں میرے ترجمے میں ان کے بلاگ GitHub Security Lab کے اعلان سے مزید پڑھ سکتے ہیں ۔ یہ ٹول، یقینا، Snyk سے آسان ہے، لیکن آپ کو یقینی طور پر اسے نظرانداز نہیں کرنا چاہیے۔ اس کے علاوہ، معلوم خطرات کی تعداد صرف بڑھے گی، لہذا Snyk اور GitHub سیکیورٹی لیب دونوں پھیلیں گے اور بہتر ہوں گے۔

سوناٹائپ ڈیپ شیلڈ کو چالو کریں۔

اگر آپ اپنے ذخیروں کو ذخیرہ کرنے کے لیے GitHub استعمال کرتے ہیں، تو آپ MarketPlace - Sonatype DepShield سے اپنے پروجیکٹس میں ایک ایپلیکیشن شامل کر سکتے ہیں۔ اس کی مدد سے، آپ انحصار کے لیے پروجیکٹس کو بھی اسکین کر سکتے ہیں۔ مزید برآں، اگر اسے کچھ مل جاتا ہے تو، ایک گٹ ہب ایشو اسی تفصیل کے ساتھ بنایا جائے گا، جیسا کہ ذیل میں دکھایا گیا ہے:

4. حساس ڈیٹا کو احتیاط سے ہینڈل کریں۔

انگریزی تقریر میں، جملہ "حساس ڈیٹا" زیادہ عام ہے۔ کلائنٹ کی ذاتی معلومات، کریڈٹ کارڈ نمبر اور دیگر ذاتی معلومات کا افشاء ناقابل تلافی نقصان کا باعث بن سکتا ہے۔ سب سے پہلے، آپ کو ایپلی کیشن کے ڈیزائن پر گہری نظر ڈالنے کی ضرورت ہے اور اس بات کا تعین کرنا ہوگا کہ آیا واقعی کسی ڈیٹا کی ضرورت ہے۔ شاید ان میں سے کچھ کی ضرورت نہیں ہے، لیکن وہ ایسے مستقبل کے لیے شامل کیے گئے ہیں جو نہ آیا ہے اور نہ ہی آنے کا امکان ہے۔ اس کے علاوہ، پروجیکٹ لاگنگ کے دوران، اس طرح کا ڈیٹا لیک ہو سکتا ہے۔ toString()حساس ڈیٹا کو اپنے لاگز میں داخل ہونے سے روکنے کا ایک آسان طریقہ یہ ہے کہ ڈومین اداروں (جیسے صارف، طالب علم، استاد، وغیرہ) کے طریقوں کو صاف کریں ۔ یہ حساس فیلڈز کو حادثاتی طور پر پرنٹ ہونے سے روکے گا۔ اگر آپ Lombok کا استعمال ایک طریقہ پیدا کرنے کے لیے کرتے ہیں toString()، تو آپ ایک تشریح کا استعمال کر سکتے ہیں @ToString.Excludeتاکہ فیلڈ کو طریقہ کے ذریعے آؤٹ پٹ میں استعمال ہونے سے روکا جا سکے toString()۔ اس کے علاوہ، بیرونی دنیا کے ساتھ ڈیٹا کا اشتراک کرتے وقت بہت محتاط رہیں۔ مثال کے طور پر، ایک HTTP اینڈ پوائنٹ ہے جو تمام صارفین کے نام دکھاتا ہے۔ صارف کی اندرونی منفرد ID دکھانے کی ضرورت نہیں ہے۔ کیوں؟ کیونکہ اسے استعمال کرتے ہوئے، حملہ آور ہر صارف کے بارے میں دوسری، زیادہ خفیہ معلومات حاصل کر سکتا ہے۔ مثال کے طور پر، اگر آپ POJOs کو JSON میں سیریلائز کرنے اور ڈی سیریلائز کرنے کے لیے جیکسن کا استعمال کرتے ہیں ، تو آپ مخصوص فیلڈز کو سیریلائز اور ڈی سیریلائز ہونے سے روکنے کے لیے @JsonIgnoreاور تشریحات کا استعمال کر سکتے ہیں۔ @JsonIgnorePropertiesعام طور پر، آپ کو مختلف جگہوں کے لیے مختلف POJO کلاسز استعمال کرنے کی ضرورت ہے۔ اس کا کیا مطلب ہے؟

1. ڈیٹا بیس کے ساتھ کام کرنے کے لیے، صرف POJO - Entity استعمال کریں۔
2. کاروباری منطق کے ساتھ کام کرنے کے لیے، ہستی کو ماڈل میں منتقل کریں۔
3. بیرونی دنیا کے ساتھ کام کرنے اور HTTP کی درخواستیں بھیجنے کے لیے، تیسرے ادارے - DTO استعمال کریں۔

اس طرح آپ واضح طور پر وضاحت کر سکتے ہیں کہ کون سے فیلڈز باہر سے نظر آئیں گے اور کون سے نہیں۔

مضبوط انکرپشن اور ہیشنگ الگورتھم استعمال کریں۔

خفیہ کسٹمر ڈیٹا کو محفوظ طریقے سے محفوظ کیا جانا چاہیے۔ ایسا کرنے کے لیے آپ کو انکرپشن استعمال کرنے کی ضرورت ہے۔ کام پر منحصر ہے، آپ کو یہ فیصلہ کرنے کی ضرورت ہے کہ کس قسم کی خفیہ کاری کو استعمال کرنا ہے۔ مزید، مضبوط انکرپشن میں زیادہ وقت لگتا ہے، اس لیے آپ کو ایک بار پھر غور کرنے کی ضرورت ہے کہ اس کی ضرورت اس پر صرف کیے گئے وقت کو کتنی درست ثابت کرتی ہے۔ یقینا، آپ الگورتھم خود لکھ سکتے ہیں۔ لیکن یہ غیر ضروری ہے۔ آپ اس علاقے میں موجودہ حل سے فائدہ اٹھا سکتے ہیں۔ مثال کے طور پر، Google Tink :

<!-- https://mvnrepository.com/artifact/com.google.crypto.tink/tink -->
<dependency>
   <groupId>com.google.crypto.tink</groupId>
   <artifactId>tink</artifactId>
   <version>1.3.0</version>
</dependency>

آئیے دیکھتے ہیں کہ اسے کیسے استعمال کیا جائے، اس کی مثال استعمال کرتے ہوئے کہ ایک طریقے سے اور دوسرے کو کیسے انکرپٹ کیا جائے:

private static void encryptDecryptExample() {
   AeadConfig.register();
   KeysetHandle handle = KeysetHandle.generateNew(AeadKeyTemplates.AES128_CTR_HMAC_SHA256);

   String plaintext = "Цой жив!";
   String aad = "Юрий Клинских";

   Aead aead = handle.getPrimitive(Aead.class);
   byte[] encrypted = aead.encrypt(plaintext.getBytes(), aad.getBytes());
   String encryptedString = Base64.getEncoder().encodeToString(encrypted);
   System.out.println(encryptedString);

   byte[] decrypted = aead.decrypt(Base64.getDecoder().decode(encrypted), aad.getBytes());
   System.out.println(new String(decrypted));
}

پاس ورڈ کی خفیہ کاری

اس کام کے لیے، غیر متناسب خفیہ کاری کا استعمال کرنا سب سے محفوظ ہے۔ کیوں؟ کیونکہ ایپلیکیشن کو واقعی میں پاس ورڈ کو ڈیکرپٹ کرنے کی ضرورت نہیں ہے۔ یہ عام نقطہ نظر ہے. حقیقت میں، جب کوئی صارف پاس ورڈ داخل کرتا ہے، تو سسٹم اسے انکرپٹ کرتا ہے اور پاس ورڈ والٹ میں موجود چیزوں سے اس کا موازنہ کرتا ہے۔ انکرپشن اسی ذرائع کا استعمال کرتے ہوئے کیا جاتا ہے، لہذا آپ ان سے ملنے کی توقع کر سکتے ہیں (اگر آپ صحیح پاس ورڈ درج کرتے ہیں؛)۔ BCrypt اور SCrypt اس مقصد کے لیے موزوں ہیں۔ دونوں کمپیوٹیشنل پیچیدہ الگورتھم کے ساتھ یک طرفہ فنکشنز (کرپٹوگرافک ہیشز) ہیں جن میں کافی وقت لگتا ہے۔ یہ بالکل وہی ہے جس کی آپ کو ضرورت ہے، کیونکہ اس کو سمجھنے میں ہمیشہ کے لئے وقت لگے گا۔ مثال کے طور پر، Spring Security الگورتھم کی ایک حد کو سپورٹ کرتا ہے۔ SCryptPasswordEncoderآپ بھی استعمال کر سکتے ہیں BCryptPasswordEncoder۔ اب جو ایک مضبوط انکرپشن الگورتھم ہے وہ اگلے سال کمزور ہو سکتا ہے۔ نتیجے کے طور پر، ہم یہ نتیجہ اخذ کرتے ہیں کہ استعمال شدہ الگورتھم کو چیک کرنا اور الگورتھم کے ساتھ لائبریریوں کو اپ ڈیٹ کرنا ضروری ہے۔

آؤٹ پٹ کے بجائے

آج ہم نے حفاظت کے بارے میں بات کی اور یقیناً بہت سی چیزیں پردے کے پیچھے رہ گئیں۔ میں نے ابھی آپ کے لیے ایک نئی دنیا کا دروازہ کھولا ہے: ایک ایسی دنیا جو اپنی زندگی بسر کرتی ہے۔ سلامتی کے ساتھ یہ وہی ہے جو سیاست کے ساتھ ہے: اگر آپ سیاست میں شامل نہیں ہوں گے تو سیاست آپ میں مشغول ہوجائے گی۔ روایتی طور پر، میں اپنے Github اکاؤنٹ کو سبسکرائب کرنے کا مشورہ دیتا ہوں ۔ وہاں میں مختلف ٹیکنالوجیز پر اپنا کام پوسٹ کرتا ہوں جن کا میں مطالعہ کرتا ہوں اور کام پر درخواست کرتا ہوں۔

مفید لنکس

جی ہاں، سائٹ پر تقریباً تمام مضامین انگریزی میں لکھے گئے ہیں۔ چاہے ہم اسے پسند کریں یا نہ کریں، انگریزی پروگرامرز کے لیے بات چیت کرنے کی زبان ہے۔ پروگرامنگ پر تمام تازہ ترین مضامین، کتابیں اور رسالے انگریزی میں لکھے گئے ہیں۔ اسی لیے میری سفارشات کے لنکس زیادہ تر انگریزی میں ہیں:

1. جواب: ابتدائی افراد کے لیے ایس کیو ایل انجیکشن
2. اوریکل: جاوا سیکیورٹی ریسورس سینٹر
3. اوریکل: جاوا SE کے لیے محفوظ کوڈنگ کے رہنما خطوط
4. Baeldung: جاوا سیکیورٹی کی بنیادی باتیں
5. میڈیم: آپ کی جاوا سیکیورٹی کو طاقتور بنانے کے لیے 10 نکات
6. Snyk: 10 جاوا سیکیورٹی کے بہترین طریقے
7. JR: GitHub سیکیورٹی لیب کا اعلان: آپ کے تمام کوڈ کو ایک ساتھ محفوظ کرنا