একাধিক ক্লায়েন্টের জন্য সুরক্ষিতভাবে ফাইল সংরক্ষণ এবং পরিবেশন করা


8

আমরা একটি ওয়েব অ্যাপে কাজ করছি, যেখানে (অন্যান্য বৈশিষ্ট্যগুলির মধ্যে) আমাদের ব্যবহারকারীরা তাদের ফাইলগুলি আপলোড করতে পারেন। তবে আমরা এই ফাইলগুলিকে আমাদের ভিপিএসে সঞ্চয় করতে পারি না কারণ স্টোরেজ স্পেস সীমিত, তাই আমরা S3 এর সাথে যাওয়ার সিদ্ধান্ত নিয়েছি।

প্রধান সমস্যাটি হ'ল আমাদের অবশ্যই নিশ্চিত করতে হবে যে ব্যবহারকারীরা কেবল তাদের নিজস্ব ডেটা অ্যাক্সেস করতে পারবেন। সুতরাং আমরা আমাদের ডাটাবেসে ফাইলগুলির তালিকা এবং তাদের অ্যাক্সেস ব্যবহারকারীর তালিকা রাখি। আমাদের সার্ভারটি সহজেই সিদ্ধান্ত নিতে পারে যে কোনও ব্যবহারকারীর একটি ফাইল অ্যাক্সেস আছে কি না। তবে কীভাবে ব্যবহারকারীদের কাছে ফাইলগুলি পরিবেশন করা যায়?

কিছু সম্ভাবনা রয়েছে যা আমি ইতিমধ্যে বিবেচনা করেছি, তবে এগুলির কোনওটিই সেরাটি বলে মনে হচ্ছে না।

1. পিএইচপি দিয়ে স্বাক্ষরিত ইউআরএল তৈরি (মেয়াদ শেষ হয়ে)

এটি একটি খুব সহজ পদ্ধতির, এটি দ্রুতও তবে খুব কুৎসিত এবং দীর্ঘ url এর ফলাফল।

এখানে কিভাবে এটা করবেন এর

2. অবরুদ্ধ ইউআরএল

এর মানে হল, আমরা এস 3 তে পঠিত জন্য ফাইল পাবলিক রাখা, কিন্তু সব ফাইল হার্ড সংরক্ষিত হয় মত নামে ফোল্ডার অনুমান করা: 24fa0b8ef0ebb6e99c64be8092d3ede20000। তবে, এটি যেতে সবচেয়ে নিরাপদ উপায় নয়। এমনকি আপনি যদি কোনও ফোল্ডারের নামটি অনুধাবন করতে না পারেন তবে এটি জানার পরে (কারণ আপনার কাছে এটির অ্যাক্সেস রয়েছে) তবে আপনি সেই লিঙ্কটি কারও সাথে ভাগ করতে পারেন (কোনও অনুমোদিত ব্যক্তি নয়)।

৩. আমাদের সার্ভারের মাধ্যমে ফাইলগুলি ডাউনলোড করুন

এর অর্থ হল যে ফাইলগুলি সরাসরি এস 3 দ্বারা পরিবেশন করা হয় না, তবে প্রথমে আমাদের সার্ভারটি এটি নিরাপদে পড়ে এবং এটি পরিবেশন করে। আমরা সত্যিই এটি চাই না :)

৪. রেফারার পরীক্ষা করা হচ্ছে

Obfuscated URL গুলি সমাধান "নিশ্চিত" অনুরোধ আমাদের সার্ভার থেকে আসে (আপনি রেফারার চেক করতে এস 3 সেট আপ করতে পারেন) দ্বারা উন্নত করা যায়। তবে এটি একটি খুব অবিশ্বাস্য সমাধান হতে পারে, কারণ সমস্ত ব্রাউজারগুলি রেফারার ডেটা প্রেরণ করে না এবং এটি নকলও হতে পারে।

বিভিন্ন ক্লায়েন্টের জন্য অ্যামাজন এস 3 থেকে নিরাপদে ফাইল পরিবেশন করার একটি ভাল উপায় কী?


1
কুৎসিত / লম্বা ইউআরএল কেন আপনি যত্নশীল? আপনি ব্যবহারকারীকে এটি টাইপ করে দিচ্ছেন না, আপনি?
সিজেজোজ

আমি সত্যিই বিশ্বাস করি যে ইউআরএলগুলি ব্যবহারকারীর অভিজ্ঞতার অংশ, এবং আমরা এগুলি খুব দীর্ঘ এবং কুরুচিপূর্ণভাবে চাই না :)
ট্যামস পাপ

2
আমি বলব সুরক্ষা এবং স্থিতিশীলতা এই ক্ষেত্রে বেশিরভাগ ইউআরএলগুলি ট্রাম্প করা উচিত। এগুলি ব্লগ পোস্টগুলিতে প্রকাশিত হয় না।
ceejayoz

উত্তর:


12

এটি আপনার জন্য "আমার সিস্টেমের আর্কিটেকচারটি করুন" এর সাথে সীমান্তবর্তী, তবে আপনার চারটি ধারণাটি পরিবর্তনশীল সুরক্ষার ক্ষেত্রে আকর্ষণীয় কেস-স্টাডিজ, সুতরাং আসুন আপনার বিকল্পগুলি চালনা করুন এবং দেখুন কীভাবে তারা ভাবেন:


৪. রেফারার পরীক্ষা করা হচ্ছে

রেফারার ক্লায়েন্ট দ্বারা সরবরাহ করা হয়। ক্লায়েন্ট-সরবরাহিত প্রমাণীকরণ / অনুমোদনের ডেটাতে সুরক্ষা দেওয়া বেশিরভাগই সুরক্ষা দেয় (আমি কেবল দাবি করতে পারি যে আপনি যেখান থেকে আমাকে আসবেন বলে প্রত্যাশা করেছেন)। প্রত্যয়
: টেরিব্যাড ধারণা - বাইপাস থেকে তুচ্ছ।


৩. আমাদের সার্ভারের মাধ্যমে ফাইলগুলি ডাউনলোড করুন

কোনও খারাপ ধারণা নয়, যতক্ষণ না আপনি ব্যান্ডউইথটি এটির জন্য ব্যয় করতে ইচ্ছুক হন এবং আপনার সার্ভারটি নির্ভরযোগ্য।
এই ধারণা ধরেই চলেছেন যে আপনি ইতিমধ্যে আপনার সাধারণ সার্ভার / অ্যাপ্লিকেশনটির জন্য সুরক্ষা সমস্যাটি সমাধান করেছেন, এটি আপনি যে বিকল্পগুলি উপস্থাপন করেছেন তার মধ্যে এটি সর্বাধিক সুরক্ষিত।
রায়: ভাল সমাধান। খুব সুরক্ষিত, তবে ব্যান্ডউইথ যদি একটি ফ্যাক্টর হয় তবে সম্ভবত সাবঅপটিমাল।


2. অবরুদ্ধ ইউআরএল

অস্পষ্টতার মধ্য দিয়ে সুরক্ষা ? সত্যি? না,
আমি এটি বিশ্লেষণ করতেও যাচ্ছি না। শুধুই না.
রায়: যদি # 4 ছিল TERRIBAD এই হল TERRIWORSE কারণ মানুষ এমনকি একটি রেফারার হেডার forging এর প্রচেষ্টা মধ্য দিয়ে যেতে হবে না। স্ট্রিংটি অনুমান করুন এবং সমস্ত ডেটা একটি পুরষ্কার জিতে নিন !


1. পিএইচপি দিয়ে স্বাক্ষরিত ইউআরএল তৈরি (মেয়াদ শেষ হয়ে)

এই বিকল্পের একটি চমত্কার কম স্তন্যপান ভাগফল আছে।
যে কেউ ইউআরএল-এ ক্লিক করতে পারেন এবং ডেটা স্নার্ফ করতে পারেন, এটি একটি সুরক্ষা নং-না, তবে আপনি লিঙ্কটির মেয়াদ উত্তীর্ণ করে এটিকে প্রশমিত করতে পারেন (যতক্ষণ না লিঙ্কের জীবন যথেষ্ট কম দুর্বলতার উইন্ডো ছোট থাকে)।
মেয়াদ শেষ হওয়া ইউআরএল এমন কিছু ব্যবহারকারীদের অসুবিধা হতে পারে যারা দীর্ঘ সময়ের জন্য ডাউনলোড লিঙ্কটিতে স্থির থাকতে চান বা সময় মতো লিঙ্কটি পান না - এটি ব্যবহারকারী অভিজ্ঞতা থেকে কিছুটা চুষতে পারে তবে এটি মূল্যবান হতে পারে ।
রায় : না # 3 হিসাবে ভাল হিসাবে, কিন্তু যদি ব্যান্ডউইডথ একটি প্রধান উদ্বেগের এটা অবশ্যই এর # চেয়ে 4 বা # 2 হয়।


আমি কি করবো?

এই বিকল্পগুলি দেওয়া, আমি # 3 নিয়ে যাব - আপনার নিজের ফ্রন্ট-এন্ড সার্ভারের মাধ্যমে ফাইলগুলি পাস করুন, এবং আপনার অ্যাপ্লিকেশনটি সাধারণত যা করে তা প্রমাণীকরণ করব। আপনার স্বাভাবিক সুরক্ষাটি বেশ শালীন বলে ধরে নেওয়া কোনও সুরক্ষা দৃষ্টিকোণ থেকে এটি সর্বোত্তম বিকল্প।
হ্যাঁ, এর অর্থ আপনার সার্ভারে আরও বেশি ব্যান্ডউইথ ব্যবহার, এবং মিডলম্যান খেলে আরও বেশি সংস্থান রয়েছে - তবে আপনি তার জন্য সামান্য কিছুটা বেশি চার্জ করতে পারেন।


এটি সত্যিই সহায়ক বিশ্লেষণ, এবং আমি এটির জন্য অত্যন্ত কৃতজ্ঞ। # 3 এর আরেকটি বড় সুবিধা হ'ল - কারণ কোনও ফাইলের url কখনই পরিবর্তন হয় না - আমরা ব্রাউজারের ক্যাচিংটি ভারীভাবে ব্যবহার করতে পারি। আপনার সময় জন্য আবার ধন্যবাদ।
ট্যামস পাপ

@ তমাসপ্যাপ যা নিশ্চিত হওয়ার জন্য # 3 এর একটি সুবিধা - আপনি কতটা আগ্রাসীভাবে ক্যাচিং কনফিগার করতে পারবেন (এবং "নতুন" মেশিনগুলি থেকে লোকেরা এই ফাইলগুলিতে কতক্ষণ অ্যাক্সেস করে) কতটা বড় সুবিধা নির্ভর করে।
voretaq7

4

আপনার ইচ্ছামত ব্যবহারকারীর যাচাই করার পরে সরাসরি ব্যবহারকারীদের S3 অবজেক্টগুলি পরিবেশন করতে অ্যামাজন এস 3 প্রাক-স্বাক্ষরিত ক্যোরিগুলি ব্যবহার করুন । এই পদ্ধতিটি একটি সময়-সীমাবদ্ধ URL তৈরি করে যাতে আপনি ব্যবহারকারীদের পুনর্নির্দেশ করতে পারেন।


0

পাশাপাশি আরও একটি উপায় আছে।

আপনি আপনার এস 3 বাল্টিতে একটি এডাব্লুএস ক্লাউডফ্রন্টকে নির্দেশ করতে পারেন এবং আপনার শেষ ব্যবহারকারীদের সুরক্ষিতভাবে সামগ্রী পরিবেশন করতে স্বাক্ষরিত কুকিজ ব্যবহার করতে পারেন।

শেষ ব্যবহারকারীদের স্বাক্ষরিত কুকিজগুলি পেতে আপনার সার্ভারে সাইন ইন করতে হবে যা কোনও ফাইল অ্যাক্সেস করার সময় সিডিএন-এ প্রেরণ করা হবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.