ការពន្យល់អំពីការអនុញ្ញាត Public_HTML៖ ការកំណត់សុវត្ថិភាពសម្រាប់ឯកសារ និងថតឯកសារ

ការអនុញ្ញាត Public_html សម្រេចថាអ្នកណាអាចអាន ផ្លាស់ប្តូរ ឬដំណើរការខ្លឹមសារដែលម៉ាស៊ីនបម្រើគេហទំព័ររបស់អ្នកបោះពុម្ពផ្សាយ។ នៅពេលដែលពួកគេបើកចំហពេក អ្នកវាយប្រហារច្រើនតែមិនត្រូវការ "ការលួចចូលកម្រិតខ្ពស់" ទេ។ ពួកគេគ្រាន់តែរកមើល ផ្ទុកឡើង ឬកែសម្រួលអ្វីដែលម៉ាស៊ីនបម្រើរបស់អ្នកអនុញ្ញាតរួចហើយ។ នៅពេលដែលពួកគេចង្អៀតពេក គេហទំព័ររបស់អ្នកខូច ការអាប់ដេតបរាជ័យ ហើយអ្នកខាតពេលវេលាក្នុងការដេញតាមកំហុស "403"។

ការណែនាំនេះពន្យល់អំពីការអនុញ្ញាត public_html ដោយប្រើពាក្យសាមញ្ញ។ វាក៏ផ្តល់នូវការកំណត់ជាក់លាក់ និងមានសុវត្ថិភាពដែលអ្នកអាចអនុវត្តលើការបង្ហោះរួមគ្នាផងដែរ។ ការ VPSឬម៉ាស៊ីនមេដែលឧទ្ទិស។ នៅតាមផ្លូវ អ្នកនឹងឃើញទិន្នន័យសុវត្ថិភាពបច្ចុប្បន្ន បូករួមទាំងឧទាហរណ៍ជាក់ស្តែងដែលអ្នកអាចចម្លង និងសម្របខ្លួនបាន។

និយមន័យរហ័ស៖ ការអនុញ្ញាត Public_html គ្រប់គ្រងអ្វីដែលម៉ាស៊ីនបម្រើគេហទំព័ររបស់អ្នកអាចអានបាន អ្វីដែលគណនីរបស់អ្នកអាចផ្លាស់ប្តូរ និងអ្វីដែលមិនគួរត្រូវបានលាតត្រដាង។ នៅក្នុងការអនុវត្ត គោលដៅរបស់អ្នកគឺសាមញ្ញ៖ រក្សា public_html ឱ្យអាចអានបានសម្រាប់ខ្លឹមសារដែលបានបោះពុម្ពផ្សាយ រក្សាការសរសេរមានកំណត់ចំពោះថតឯកសារមួយចំនួនដែលត្រូវការវា និងរក្សាការសម្ងាត់នៅខាងក្រៅឫសគេហទំព័រ។

អ្វីដែល "public_html" ពិតជាមានន័យនៅលើ Modern Hosting

១. Public_html គឺជាថតឯកសារដែលបានបោះពុម្ពផ្សាយតាមគេហទំព័ររបស់អ្នក (ជាធម្មតា)

នៅលើម៉ាស៊ីនមេ Linux ជាច្រើន public_html ដើរតួជាឯកសារ root របស់គេហទំព័ររបស់អ្នក។ ម្យ៉ាងវិញទៀត ម៉ាស៊ីនបម្រើគេហទំព័រភ្ជាប់ URL ទៅកាន់ឯកសារនៅក្នុងថតឯកសារនោះ។ ប្រសិនបើឯកសារមួយរស់នៅទីនោះ ហើយម៉ាស៊ីនបម្រើអាចអានវាបាន អ្នកទស្សនាជាធម្មតាអាចទាញយកវាតាមរយៈកម្មវិធីរុករកតាមអ៊ីនធឺណិត។

ការគូសផែនទីសាមញ្ញនោះជំរុញការសម្រេចចិត្តលើការអនុញ្ញាតភាគច្រើន។ អ្នកចង់ឱ្យម៉ាស៊ីនមេគេហទំព័រអានទំព័រ រូបភាព និងស្គ្រីបរបស់អ្នក។ ទោះជាយ៉ាងណាក៏ដោយ អ្នកមិនចង់ឱ្យអ្នកប្រើប្រាស់ចៃដន្យនៅលើម៉ាស៊ីនមេ (ឬដំណើរការដែលរងការសម្របសម្រួល) កែសម្រួលពួកវាទេ។

២. ហានិភ័យពិតប្រាកដ៖ ការបោះពុម្ពផ្សាយច្រើនជាងអ្វីដែលអ្នកចង់បាន

«គ្រោះមហន្តរាយនៃការអនុញ្ញាត» ភាគច្រើនមិនចាប់ផ្តើមជាមួយនឹងឯកសារមិនល្អតែមួយនោះទេ។ ពួកវាចាប់ផ្តើមជាមួយនឹងលំហូរការងារដ៏រញ៉េរញ៉ៃ។ មាននរណាម្នាក់ផ្ទុកឡើងឯកសារបម្រុងទុក zip ទៅក្នុង public_htmlមាននរណាម្នាក់នាំចេញទិន្នន័យទិន្នន័យទៅក្នុងថតឯកសារដូចគ្នា។ មាននរណាម្នាក់រក្សាទុកកូនសោ API នៅក្នុងឯកសារអត្ថបទដែលអាចអានបាន "មួយភ្លែតប៉ុណ្ណោះ"។

បន្ទាប់មក ម៉ាស៊ីនស្កេននឹងចូលមើលគេហទំព័ររបស់អ្នក។ ប្រសិនបើការអនុញ្ញាតអនុញ្ញាតឱ្យអាន ម៉ាស៊ីនស្កេននឹងឈ្នះ។ ប្រសិនបើការអនុញ្ញាតអនុញ្ញាតឱ្យសរសេរ ម៉ាស៊ីនស្កេនអាចនឹងដាក់មេរោគ។

៣. ការបង្ហោះរួមគ្នាទល់នឹង VPS៖ គោលដៅដូចគ្នា យន្តការផ្សេងគ្នា

ចែករំលែកបង្ហោះ ជាធម្មតាដំណើរការអតិថិជនច្រើននៅលើម៉ាស៊ីនមេមួយ។ ដោយសារតែហេតុផលនោះ ជង់បង្ហោះច្រើនតែបន្ថែមរបាំងការពារបន្ថែម ដូចជាការញែកអ្នកប្រើប្រាស់ម្នាក់ៗ និងកម្មវិធីដោះស្រាយ PHP ដែលរឹងរូស។ យ៉ាងណាក៏ដោយ អ្នកត្រូវតែសន្មតថាគណនីផ្សេងទៀតមាននៅលើប្រអប់ដូចគ្នា។ ការពិតនោះធ្វើឱ្យការកំណត់ "អាចសរសេរបានលើពិភពលោក" មានគ្រោះថ្នាក់ជាពិសេស។

នៅលើ VPS ជារឿយៗអ្នកគ្រប់គ្រងអ្នកប្រើប្រាស់ម៉ាស៊ីនមេគេហទំព័រ គណនីសេវាកម្ម លំហូរការដាក់ពង្រាយ និងភាពជាម្ចាស់ឯកសារ។ ការគ្រប់គ្រងនោះជួយបាន ប៉ុន្តែវាក៏បង្កើនកាំនៃការផ្ទុះនៃកំហុសតែមួយផងដែរ។ ដូច្នេះអ្នកគួរតែនៅតែចាត់ទុកសិទ្ធិ public_html ជាការគ្រប់គ្រងជួរទីមួយ មិនមែនជាការជួសជុលនៅនាទីចុងក្រោយទេ។

ច្បាប់ជាក់ស្តែង៖ នៅលើការបង្ហោះដែលបានចែករំលែក បញ្ហាការអនុញ្ញាតច្រើនតែកើតចេញពីការញែកគណនី និងរបៀបដែល PHP ដំណើរការក្រោមអ្នកប្រើប្រាស់របស់អ្នក។ នៅលើ VPS បញ្ហាការអនុញ្ញាតច្រើនតែកើតចេញពីភាពជាម្ចាស់មិនត្រូវគ្នារវាងអ្នកប្រើប្រាស់ដាក់ពង្រាយរបស់អ្នក និងអ្នកប្រើប្រាស់ម៉ាស៊ីនមេគេហទំព័រ។ ដូច្នេះ សូមបញ្ជាក់ភាពជាម្ចាស់ជាមុនសិន បន្ទាប់មកកែសម្រួលការអនុញ្ញាតជាបន្ទាប់។

របៀបដែលការអនុញ្ញាត Linux គ្រប់គ្រងការចូលប្រើឯកសារគេហទំព័រ

១. អាន សរសេរ ប្រតិបត្តិ៖ ការផ្លាស់ប្តូរអត្ថន័យនៅលើថតឯកសារ

ការអនុញ្ញាត​របស់ Linux មើលទៅសាមញ្ញ​រហូតដល់អ្នកចាំព័ត៌មានលម្អិតសំខាន់មួយ៖ “execute” មានឥរិយាបទខុសគ្នានៅលើថតឯកសារជាងនៅលើឯកសារ។ សម្រាប់ឯកសារ execute មានន័យថា “ដំណើរការវាជាកម្មវិធី”។ សម្រាប់ថតឯកសារ execute ធ្វើសកម្មភាពដូចជា “traverse/search”។ បើគ្មានវាទេ ដំណើរការមួយមិនអាចចូលប្រើឯកសារនៅក្នុងថតឯកសារបានទេ ទោះបីជាការអនុញ្ញាតឯកសារមើលទៅបើកចំហក៏ដោយ។

ឧទាហរណ៍សាមញ្ញ៖ អ្នកអាចផ្តល់សិទ្ធិឯកសារដែលមើលទៅអាចអានបាន ប៉ុន្តែប្រសិនបើថតឯកសារមេរារាំងការឆ្លងកាត់ ម៉ាស៊ីនមេមិនអាចចូលទៅកាន់ឯកសារបានទេ។ នោះហើយជាមូលហេតុដែលទំព័រមួយអាចបោះចោលកំហុសហាមឃាត់ភ្លាមៗបន្ទាប់ពីការផ្លាស់ប្ដូរសិទ្ធិថតឯកសារ ទោះបីជាឯកសារខ្លួនឯងហាក់ដូចជាល្អក៏ដោយ។

នេះពន្យល់ពីអាថ៌កំបាំងទូទៅមួយ៖ ឯកសារមួយអាចបង្ហាញប៊ីតដែលអាចអានបាន ប៉ុន្តែកម្មវិធីរុករករបស់អ្នកនៅតែបង្ហាញកំហុសហាមឃាត់ ពីព្រោះថតឯកសារខាងលើរារាំងការឆ្លងកាត់។

២. ភាពជាម្ចាស់កម្មសិទ្ធិមានសារៈសំខាន់ដូចរបៀបរស់នៅដែរ

ឯកសារនីមួយៗមានម្ចាស់ និងក្រុម។ ប៊ីតនៃការអនុញ្ញាតត្រូវបានអនុវត្តតាមលំដាប់លំដោយ៖ ម្ចាស់គ្រប់គ្រងមុនគេ បន្ទាប់មកច្បាប់ក្រុម បន្ទាប់មក "ផ្សេងទៀត"។ លំដាប់នោះមានន័យថា អ្នកអាចរឹតបន្តឹង "ផ្សេងទៀត" បានច្រើន ប្រសិនបើអ្នករក្សាភាពជាម្ចាស់បានត្រឹមត្រូវ។

បញ្ជីត្រួតពិនិត្យខ្លីមួយស្តីពី “ភាពជាម្ចាស់កម្មសិទ្ធិជាមុន”៖

• សូមបញ្ជាក់ថាឯកសារគេហទំព័ររបស់អ្នកជាកម្មសិទ្ធិរបស់គណនីដែលដាក់ពង្រាយ និងធ្វើបច្ចុប្បន្នភាពពួកវា។
• បញ្ជាក់ថាដំណើរការម៉ាស៊ីនបម្រើគេហទំព័រមានការចូលប្រើអប្បបរមាដែលវាត្រូវការ។
• ជួសជុលភាពមិនត្រូវគ្នានៃកម្មសិទ្ធិ មុនពេលអ្នកផ្លាស់ប្តូររបៀបអនុញ្ញាត។
• សាកល្បងសកម្មភាពគេហទំព័រឡើងវិញដែលតម្រូវឱ្យមានការសរសេរ ដូចជាការផ្ទុកឡើង និងការអាប់ដេត បន្ទាប់ពីការផ្លាស់ប្តូរតិចតួចនីមួយៗ។

នៅក្នុងន័យជាក់ស្តែង អ្នកចង់ឱ្យអ្នកប្រើប្រាស់ដាក់ពង្រាយរបស់អ្នក (ឬគណនីរបស់អ្នក) ជាម្ចាស់ឯកសារគេហទំព័រ។ អ្នកក៏ចង់ឱ្យដំណើរការម៉ាស៊ីនបម្រើគេហទំព័រមានសិទ្ធិចូលប្រើដែលវាត្រូវការផងដែរ។ ការណែនាំរបស់ Apache ថែមទាំងសង្កត់ធ្ងន់ថាម៉ាស៊ីនបម្រើ មិនត្រូវការសិទ្ធិសរសេរនៅកន្លែងណាមួយនៅលើប្រព័ន្ធទេ តាមលំនាំដើម ដែលតម្រឹមជាមួយឫសបណ្ដាញដែលមានសុវត្ថិភាពជាង។

៣. ACLs និង “Special Bits” អាចជំនួសការរំពឹងទុក

ប៊ីតរបៀបបុរាណ (ទង់ rwx ដែលធ្លាប់ស្គាល់) មិនប្រាប់រឿងរ៉ាវទាំងមូលនៅលើប្រព័ន្ធនីមួយៗទេ។ ម៉ាស៊ីនជាច្រើនប្រើ ACL សម្រាប់ការគ្រប់គ្រងដ៏ល្អិតល្អន់។ ដូចគ្នានេះដែរ setuid, setgid និងប៊ីតស្អិតអាចផ្លាស់ប្តូររបៀបដែលការប្រតិបត្តិ និងការលុបដំណើរការ។

ដូច្នេះនៅពេលអ្នកដោះស្រាយបញ្ហា កុំឈប់នៅត្រឹមនេះ ls -lពិនិត្យមើល ACL ជាមួយ getfacl នៅពេលដែលអ្វីមួយហាក់ដូចជា "មិនអាចទៅរួច"។

ប្រសិនបើការអនុញ្ញាតមើលទៅត្រឹមត្រូវ ប៉ុន្តែឥរិយាបថនៅតែខុស សូមសង្ស័យ ACL ឬការគ្រប់គ្រងកម្រិតម៉ាស៊ីន ហើយផ្ទៀងផ្ទាត់ពួកវាមុនពេលអ្នកធ្វើការផ្លាស់ប្តូរកាន់តែទូលំទូលាយ។

ការអនុញ្ញាត Safe Public_html៖ ការកំណត់ដែលបានណែនាំសម្រាប់ឯកសារ និងថតឯកសារ

១. មូលដ្ឋានគ្រឹះជាក់ស្តែងដែលអ្នកអាចចាប់ផ្តើមជាមួយថ្ងៃនេះ

ការកំណត់ទាំងនេះដំណើរការល្អសម្រាប់គេហទំព័រ PHP ជាច្រើន គេហទំព័រឋិតិវន្ត និងគេហទំព័រទូទៅ។ CMS ការដំឡើង។ ពួកគេសន្មតថាគណនីរបស់អ្នកជាម្ចាស់ឯកសារ ហើយម៉ាស៊ីនមេគេហទំព័រត្រូវការសិទ្ធិចូលអានសម្រាប់ខ្លឹមសារភាគច្រើនប៉ុណ្ណោះ។

បន្ទាប់ពីអ្នកកំណត់បន្ទាត់គោលរួចហើយ សូមព្យាយាមកាត់បន្ថយតំបន់ដែលអាចសរសេរបាន។ ប្រសិនបើកម្មវិធីរបស់អ្នកត្រូវការផ្ទុកឡើង សូមរក្សាភាពអាចសរសេរបាននោះនៅក្នុងថតឯកសារដែលឧទ្ទិសដល់។ ការសម្រេចចិត្តតែមួយនោះធ្វើឱ្យឧប្បត្តិហេតុនៅពេលក្រោយកាន់តែងាយស្រួលក្នុងការសម្អាត។

2. រឹតបន្តឹងការអនុញ្ញាតដោយការផ្លាស់ប្តូរអាថ៌កំបាំងចេញពី Root គេហទំព័រ

ការអនុញ្ញាតជួយបានច្រើន ប៉ុន្តែទីតាំងជួយបានច្រើនជាង។ ប្រសិនបើអ្នករក្សាទុកអាថ៌កំបាំងនៅក្នុង public_html អ្នកបង្ខំខ្លួនឯងឱ្យពឹងផ្អែកលើម៉ាស៊ីនមេគេហទំព័រដែលមិនដែលបង្ហាញវាឡើយ។ នោះជាការភ្នាល់ដ៏ផុយស្រួយមួយ។

ផ្ទុយទៅវិញ សូមដាក់ឯកសាររសើបនៅពីលើ root គេហទំព័រ នៅពេលដែលម៉ាស៊ីនបម្រើរបស់អ្នកអនុញ្ញាត។ ឧទាហរណ៍ រក្សាទុកឯកសារកំណត់រចនាសម្ព័ន្ធឯកជននៅក្នុងថតផ្ទះរបស់អ្នក ហើយឱ្យកម្មវិធីរបស់អ្នកអានវាពីទីនោះ។ ប្រសិនបើអ្នកដំណើរការក្របខ័ណ្ឌមួយ សូមជ្រើសរើសអថេរបរិស្ថាន ឬកម្មវិធីគ្រប់គ្រងសម្ងាត់។

បញ្ជីត្រួតពិនិត្យ "កន្លែងដែលអាថ៌កំបាំងជាធម្មតាលាក់ខ្លួន"៖

• ឯកសារបរិស្ថានដែលប្រើដោយក្របខ័ណ្ឌ និងស្គ្រីបដាក់ពង្រាយ។
• បណ្ណសារបម្រុងទុក និងឯកសារនាំចេញដែលបានបង្កើតឡើងក្នុងអំឡុងពេលការងារធ្វើចំណាកស្រុក។
• ច្បាប់ចម្លងការកំណត់រចនាសម្ព័ន្ធចាស់ៗដែលបានធ្វើឡើងកំឡុងពេលដោះស្រាយបញ្ហា។
• កូនសោឯកជន ព័ត៌មានផ្ទៀងផ្ទាត់សេវាកម្ម និងថូខឹន API ត្រូវបានរក្សាទុកក្នុងឯកសារអត្ថបទ។

លំដាប់ដែលពេញចិត្ត៖ រក្សា​ការសម្ងាត់​នៅខាងក្រៅ public_html ជាមុនសិន។ ប្រសិនបើ​មិនអាចធ្វើបានទេ សូមការពារ​ពួកវា​ដោយច្បាប់​ម៉ាស៊ីនមេ​បន្ទាប់។ បន្ទាប់មក​គ្រាន់តែពឹងផ្អែកលើ​ការអនុញ្ញាត​ជាស្រទាប់សុវត្ថិភាពចុងក្រោយ។

៣. ជៀសវាងការផ្លាស់ប្តូរការអនុញ្ញាត "ជួសជុលរហ័ស" ដែលបង្កើតហានិភ័យរយៈពេលវែង

ក្រុមជាច្រើន «ដោះស្រាយ» កំហុសក្នុងការអាប់ដេតកម្មវិធីជំនួយដោយធ្វើឱ្យថតឯកសារអាចសរសេរបានសម្រាប់មនុស្សគ្រប់គ្នា។ ការអាប់ដេតទទួលបានជោគជ័យ ដូច្នេះការផ្លាស់ប្តូរនៅតែមាន។ ប៉ុន្មានសប្តាហ៍ក្រោយមក អ្នកវាយប្រហារបានរកឃើញផ្លូវដែលអាចសរសេរបាននោះ ហើយទម្លាក់ឯកសារខាងក្រោយ។

ឯកសារ WordPress ព្រមានយ៉ាងច្បាស់ថា មិនគួរមានថតឯកសារណាមួយត្រូវបានផ្តល់លេខ 777 ឡើយ ពីព្រោះវាបង្កើតគោលដៅសរសេរងាយស្រួលលើការដំឡើងម៉ាស៊ីនមេជាច្រើន។ ជំហានដែលមានសុវត្ថិភាពជាងគឺត្រូវជួសជុលភាពជាម្ចាស់ ការកំណត់រចនាសម្ព័ន្ធកម្មវិធីដោះស្រាយ PHP ឬលំហូរដាក់ពង្រាយ ដូច្នេះកម្មវិធីអាចសរសេរបានតែកន្លែងដែលវាពិតជាត្រូវធ្វើប៉ុណ្ណោះ។

ហេតុអ្វីបានជារឿងនេះសំខាន់ឥឡូវនេះ៖ ទិន្នន័យសុវត្ថិភាពថ្មីៗជាប់ទាក់ទងនឹងការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ និងការចូលប្រើ

១. ការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវរក្សាចំណាត់ថ្នាក់នៅជិតកំពូលសម្រាប់ហានិភ័យគេហទំព័រ

OWASP តាមដានទិន្នន័យពិភពពិតនៅទូទាំងប្រភពជាច្រើន។ នៅក្នុងបញ្ជីចុងក្រោយបំផុតរបស់ខ្លួន ប្រភេទការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវបង្ហាញ 719,084 ការកើតឡើងនៅក្នុងសំណុំទិន្នន័យដែលបានរួមចំណែក ដែលបង្ហាញពីភាពញឹកញាប់ដែលក្រុមនានាផ្ញើការខកខានមិនមានសុវត្ថិភាព ឬការពង្រឹងភាពរឹងមាំមិនស៊ីសង្វាក់គ្នា។

ការអនុញ្ញាត Public_html ស្ថិតនៅក្នុងចន្លោះបញ្ហាពិតប្រាកដនេះ។ ពួកវាជាផ្នែកមួយនៃ "ការពង្រឹង" របស់អ្នក។ នៅពេលអ្នកចាត់ទុកពួកវាជាកិច្ចការដំឡើងម្តង ការរសាត់ចូលដោយចៃដន្យ។

ការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវជារឿយៗមើលទៅគួរឱ្យធុញនៅពេលគិតទៅក្រោយ។ ជាធម្មតាវាជាការផ្ទុកឡើងយ៉ាងប្រញាប់ប្រញាល់ ការបម្រុងទុកបណ្ដោះអាសន្ន ថតឯកសារដែលអាចសរសេរបាន "គ្រាន់តែដើម្បីបញ្ចប់ការអាប់ដេត" ឬឫសគេហទំព័រដែលក្លាយជាកន្លែងផ្ទុកទិន្នន័យបន្តិចម្តងៗ។ ការជួសជុលនេះដំណើរការហើយ៖ រក្សា public_html ឱ្យស្អាត រក្សាតំបន់ដែលអាចសរសេរបានឱ្យតូច និងពិនិត្យឡើងវិញបន្ទាប់ពីការផ្លាស់ប្តូរសំខាន់ៗណាមួយ។

2. បរិមាណ​នៃ​ការ​បំពាន​នៅ​តែ​ខ្ពស់ ដូច្នេះ​កំហុស​តូចតាច​កើនឡើង​យ៉ាង​ឆាប់រហ័ស

វាត្រូវការតែការបម្រុងទុកដែលបានបង្ហាញមួយ ឬថតស្គ្រីបដែលអាចសរសេរបានមួយប៉ុណ្ណោះ ដើម្បីបង្កើតឧប្បត្តិហេតុពេញលេញមួយ។ DBIR របស់ Verizon បង្ហាញពីវិសាលភាពនៃបញ្ហា ជាមួយ ការលួចទិន្នន័យចំនួន ១២.១៩៥ ដែលបានបញ្ជាក់ បានវិភាគនៅក្នុងសំណុំទិន្នន័យរបស់របាយការណ៍។

មាត្រដ្ឋាននោះមានសារៈសំខាន់ ពីព្រោះអ្នកវាយប្រហារធ្វើស្វ័យប្រវត្តិកម្មការរកឃើញ។ ពួកគេមិន "រើសអើង" តែលើម៉ាកល្បីៗនោះទេ។ ពួកគេស្វែងរកឱកាសការងារដែលមិនសូវមានតម្រូវការខ្ពស់។

៣. ថ្លៃដើមនៃការធ្វើខុសនៅតែធ្ងន់ធ្ងរ

សូម្បីតែឧប្បត្តិហេតុគេហទំព័រតូចមួយក៏អាចវិវត្តទៅជាពេលវេលារងចាំ ការសម្អាត ការគាំទ្រអតិថិជន និងការខូចខាតកេរ្តិ៍ឈ្មោះផងដែរ។ IBM រាយការណ៍ពីការចំណាយជាមធ្យមលើការរំលោភបំពានទូទាំងពិភពលោកចំនួន ១៣៤ លានដុល្លារនៅឆ្នាំ ២០២៣ដែលជួយពន្យល់ពីមូលហេតុដែលការគ្រប់គ្រងជាមូលដ្ឋានដូចជាសិទ្ធិតិចតួចបំផុតនៅតែមានសារៈសំខាន់។

ការអនុញ្ញាតមិនបញ្ឈប់រាល់ការរំលោភបំពានទាំងអស់នោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ ជារឿយៗវារារាំង "ផ្លូវងាយស្រួល" ដែលប្រែក្លាយកំហុសតូចតាចទៅជាការសម្របសម្រួលទាំងស្រុង។

៤. បញ្ហា​ការ​ប៉ះពាល់​ខ្លាំង​ពេក​លេចឡើង​នៅ​គ្រប់​ទីកន្លែង មិន​ត្រឹម​តែ​នៅ​លើ​ឫស​បណ្ដាញ​ប៉ុណ្ណោះ​ទេ

គំរូ "បើកចំហពេក" ដូចគ្នានេះក៏បង្ហាញនៅក្នុងទ្រព្យសកម្មលើពពកផងដែរ។ Wiz បានរកឃើញថា 54% នៃបរិស្ថានពពក បានលាតត្រដាង VMs និង instances គ្មានម៉ាស៊ីនមេដែលមានព័ត៌មានរសើប ដែលពង្រឹងមេរៀនដែលស៊ីសង្វាក់គ្នា៖ ក្រុមនានាច្រើនតែបោះពុម្ពផ្សាយច្រើនជាងអ្វីដែលពួកគេបានដឹង។

ដូច្នេះ សូមចាត់ទុកការអនុញ្ញាត public_html ជាផ្នែកមួយនៃវិន័យធំជាង។ អ្នកចង់បានការបង្ហាញដោយចេតនា មិនមែនការបង្ហាញដោយចៃដន្យទេ។

ដំណើរការមួយជំហានម្តងៗដើម្បីធ្វើសវនកម្ម និងជួសជុលការអនុញ្ញាត Public_html

១. ធ្វើ​បញ្ជី​សារពើភ័ណ្ឌ​អ្វី​ដែល​អ្នក​ពិតជា​បម្រើ

ចាប់ផ្តើមជាមួយសំណួរសាមញ្ញមួយ៖ "តើអ៊ីនធឺណិតគួរទៅដល់ឯកសារអ្វីខ្លះ?" រាយបញ្ជីពួកវាតាមប្រភេទ៖

• ខ្លឹមសារសាធារណៈ៖ HTML, CSS, JS, រូបភាព, ពុម្ពអក្សរ
• កូដកម្មវិធី៖ PHP, គំរូ, ទ្រព្យសកម្មដែលបានចងក្រង
• ផ្ទុកឡើងមាតិកា៖ រូបភាពអ្នកប្រើប្រាស់ ឯកសារ
• អាថ៌កំបាំង៖ ឯកសារបរិស្ថាន កូនសោឯកជន ការបម្រុងទុក ការចាក់ចោលមូលដ្ឋានទិន្នន័យ

បន្ទាប់មកចាត់វិធានការយ៉ាងរហ័សលើប្រភេទចុងក្រោយ។ ប្រសិនបើពាក្យសម្ងាត់ស្ថិតនៅក្រោម public_html សូមផ្លាស់ទីវាចេញជាមុនសិន។ ការផ្លាស់ប្តូរនោះកាត់បន្ថយហានិភ័យភ្លាមៗ សូម្បីតែមុនពេលអ្នកផ្លាស់ប្តូរប៊ីតការអនុញ្ញាតតែមួយក៏ដោយ។

2. បញ្ជាក់​ភាពជាម្ចាស់​មុនពេល​អ្នក​ប៉ះ​ម៉ូដ​នានា

“បញ្ហា​ការអនុញ្ញាត” ជាច្រើន​ពិតជា​បញ្ហា​កម្មសិទ្ធិ។ ឧទាហរណ៍ បំពង់​ដាក់ពង្រាយ​អាច​ផ្ទុក​ឡើង​ឯកសារ​ជា root។ បន្ទាប់មកអ្នកប្រើប្រាស់ធម្មតារបស់អ្នកមិនអាចធ្វើបច្ចុប្បន្នភាពពួកគេបានទេ។ ដូច្នេះអ្នកបន្ធូរបន្ថយការអនុញ្ញាតដើម្បីទូទាត់សង ហើយអ្នកបង្កើតហានិភ័យ។

ផ្ទុយទៅវិញ សូមកំណត់ភាពជាម្ចាស់កម្មសិទ្ធិ ដើម្បីឱ្យគណនីត្រឹមត្រូវអាចគ្រប់គ្រងឯកសារបាន។ នៅលើ VPS ជារឿយៗមានន័យថាធានាថាអ្នកប្រើប្រាស់ដាក់ពង្រាយរបស់អ្នកជាម្ចាស់មែកធាងគេហទំព័រ ខណៈពេលដែលម៉ាស៊ីនមេគេហទំព័រដំណើរការជាអ្នកប្រើប្រាស់ដាច់ដោយឡែកដែលមានសិទ្ធិមានកំណត់។ នៅលើការបង្ហោះដែលបានចែករំលែក ជាធម្មតាវាមានន័យថារក្សាភាពជាម្ចាស់កម្មសិទ្ធិលើ cPanel អ្នកប្រើប្រាស់ និងជៀសវាងការសរសេរជាក្រុមអ្នកប្រើប្រាស់ឆ្លង។

៣. កំណត់ការអនុញ្ញាតឡើងវិញដោយប្រើ Symbolic chmod (មានសុវត្ថិភាពក្នុងការអាន)

របៀបនិមិត្តសញ្ញាជួយអ្នកបង្ហាញចេតនាដោយមិនចាំបាច់ទន្ទេញលេខ។ ពួកវាក៏ធ្វើឱ្យការពិនិត្យឡើងវិញកាន់តែងាយស្រួលផងដែរ ពីព្រោះអ្នកអាចអានការផ្លាស់ប្តូរជា "ម្ចាស់ត្រូវបានអាន/សរសេរ" ជាជាង "កំណត់ទៅតម្លៃគោលប្រាំបីមួយចំនួន"។

សៀវភៅណែនាំ chmod ពិពណ៌នាអំពីរបៀបជា តំណាងនិមិត្តរូបនៃការផ្លាស់ប្តូរដែលត្រូវធ្វើដែលសមល្អសម្រាប់ការងាររឹងដោយប្រុងប្រយ័ត្ន។

ខាងក្រោមនេះជាឧទាហរណ៍ដែលអ្នកអាចសម្របខ្លួនបាន៖

• ធ្វើឱ្យឯកសារអាចអានបានដោយមនុស្សគ្រប់គ្នា អាចសរសេរបានដោយម្ចាស់តែប៉ុណ្ណោះ៖ chmod u=rw,go=r yourfile
• បង្កើតថតឯកសារដែលអាចឆ្លងកាត់បាន និងអាចរាយបញ្ជីបាន ប៉ុន្តែអាចសរសេរបានដោយម្ចាស់តែប៉ុណ្ណោះ៖ chmod u=rwx,go=rx yourdir
• ចាក់សោឯកសារសម្ងាត់សម្រាប់តែម្ចាស់ប៉ុណ្ណោះ៖ chmod u=rw,go= yoursecret

បន្ទាប់ពីនោះ អនុវត្តការផ្លាស់ប្តូរជាបាច់តូចៗ។ បន្ទាប់មកផ្ទុកទំព័រសំខាន់ៗ ចូល ផ្ទុកឡើងមេឌៀ និងដំណើរការការអាប់ដេតអ្នកគ្រប់គ្រងណាមួយ។ ជំហានសាកល្បងនេះការពារ "ការវិលត្រឡប់" ដ៏ប្រញាប់ប្រញាល់ ដែលជារឿយៗនាំឱ្យមានផ្លូវកាត់ការអនុញ្ញាតដែលមានហានិភ័យ។

៤. ផ្ទៀងផ្ទាត់ជាមួយទិដ្ឋភាពម៉ាស៊ីនបម្រើបណ្ដាញ មិនមែនគ្រាន់តែទិដ្ឋភាពសែលទេ

ការត្រួតពិនិត្យ Shell ប្រាប់អ្នកពីអ្វីដែលប្រព័ន្ធឯកសារអនុញ្ញាត។ ការត្រួតពិនិត្យកម្មវិធីរុករកតាមអ៊ីនធឺណិតប្រាប់អ្នកពីអ្វីដែលសាធារណជនអាចចូលប្រើបាន។ អ្នកត្រូវការទាំងពីរ។

ប្រើរង្វិលជុំផ្ទៀងផ្ទាត់រហ័សនេះ៖

• បើកទំព័រសាធារណៈធម្មតាមួយ ហើយបញ្ជាក់ថាវាផ្ទុក។
• ទាញយកឯកសារដែលមិនគួរបង្ហាញជាសាធារណៈ (ឧទាហរណ៍៖ ឈ្មោះបម្រុងទុកដែលអ្នកបានប្រើពីមុន)។ សូមបញ្ជាក់ថាអ្នកទទួលបាន 404 ឬ 403។
• បង្ហោះរូបភាពសាកល្បង ប្រសិនបើគេហទំព័ររបស់អ្នកគាំទ្រការបង្ហោះ បន្ទាប់មកបញ្ជាក់ថាវាដំណើរការបានត្រឹមត្រូវ។
• សូមពិនិត្យមើលកំណត់ហេតុម៉ាស៊ីនមេសម្រាប់កំហុសក្នុងការអនុញ្ញាត និងការលេចធ្លាយផ្លូវ។

ដូចគ្នានេះដែរ សូមប្រយ័ត្នចំពោះការធ្វើលិបិក្រមដោយចៃដន្យ។ ប្រសិនបើថតឯកសារបង្ហាញបញ្ជីឯកសារនៅក្នុងកម្មវិធីរុករក អ្នកទំនងជាបានបើកការរាយបញ្ជីថត ឬខកខាន សន្ទស្សន៍ ច្បាប់។

ឧទាហរណ៍ជាក់ស្តែង៖ ការអនុញ្ញាតដែលមានសុវត្ថិភាពសម្រាប់សេណារីយ៉ូគេហទំព័រទូទៅ

១. WordPress លើ Shared Hosting (ការដំឡើង cPanel ធម្មតា)

WordPress ជារឿយៗត្រូវសរសេរទៅកាន់ថតឯកសារជាក់លាក់ដូចជា ឯកសារផ្ទុកឡើង ឃ្លាំងសម្ងាត់ និងជួនកាលផ្លូវអាប់ដេតកម្មវិធីជំនួយ។ ទោះជាយ៉ាងណាក៏ដោយ វាមិនត្រូវការការអនុញ្ញាតសរសេរទូលំទូលាយនៅទូទាំងដើមឈើគេហទំព័រទាំងមូលនោះទេ។

ដូច្នេះ សូមចាប់ផ្តើមពីមូលដ្ឋានទិន្នន័យរបស់អ្នកសម្រាប់ការអនុញ្ញាត public_html។ បន្ទាប់មក បង្រួមការសរសេរទៅតែថតឯកសារដែល WordPress ពិតជាប្រើសម្រាប់ការសរសេរប៉ុណ្ណោះ។ នៅក្នុងការដំឡើង WordPress ភាគច្រើន ការសរសេរគួរតែត្រូវបានកំណត់ចំពោះកន្លែងដែលរក្សាទុកខ្លឹមសារដែលបង្កើតដោយអ្នកប្រើប្រាស់ និងវត្ថុបុរាណពេលដំណើរការបណ្ដោះអាសន្ន។ រក្សាវិសាលភាពសរសេរនោះឱ្យតូច ហើយចាត់ទុកថតឯកសារថ្មីដែលអាចសរសេរបានណាមួយជាការសម្រេចចិត្តដោយចេតនាដែលអ្នកកត់ត្រាសម្រាប់ការធ្វើសវនកម្មនាពេលអនាគត។

ប្រសិនបើការអាប់ដេតបរាជ័យ សូមជួសជុលគំរូប្រតិបត្តិ (ឧទាហរណ៍ ការកំណត់ PHP-FPM) ឬភាពជាម្ចាស់។ ជៀសវាងការ "ធ្វើឱ្យអ្វីៗគ្រប់យ៉ាងអាចសរសេរបាន" ជាទម្លាប់។

ដូចគ្នានេះដែរ សូមរក្សាការបម្រុងទុកឱ្យនៅឆ្ងាយពីឫសគេហទំព័រ។ ប្រសិនបើអ្នកត្រូវតែរក្សាទុកការបម្រុងទុកនៅលើម៉ាស៊ីនមេដូចគ្នា សូមដាក់វានៅពីលើ public_html ហើយកំណត់ការអានឱ្យតឹងរ៉ឹង។

2. Laravel, Symfony និង Framework ផ្សេងទៀតដែលមាន Folder “public/”

ការដំឡើង Framework ជារឿយៗបង្ហាញតែថតឯកសារតូចមួយទៅកាន់ម៉ាស៊ីនបម្រើគេហទំព័រ។ ឧទាហរណ៍ Laravel ជាធម្មតាបម្រើពី public ថតឯកសារ ខណៈពេលដែលកូដកម្មវិធីស្ថិតនៅខាងក្រៅថតឯកសារនោះ។

ប្លង់នេះធ្វើឱ្យការឡើងរឹងកាន់តែងាយស្រួលព្រោះអ្នកអាច៖

• បង្ហាញតែទ្រព្យសកម្មដែលបានចងក្រង និងឧបករណ៍បញ្ជាខាងមុខប៉ុណ្ណោះ។
• រក្សា .env ឯកសារនៅខាងក្រៅថតដែលបានបម្រើ។
• កំណត់ថតឯកសារដែលអាចសរសេរបានចំពោះផ្លូវផ្ទុក និងផ្លូវឃ្លាំងសម្ងាត់។

ប្រសិនបើអ្នកកំពុងដំណើរការ framework ពី public_html ដោយផ្ទាល់ សូមពិចារណារៀបចំរចនាសម្ព័ន្ធឡើងវិញ។ ការផ្លាស់ប្តូរនោះជាធម្មតាកាត់បន្ថយហានិភ័យច្រើនជាងការកែប្រែ permission ណាមួយ។

រដ្ឋល្អ៖ ឯកសារ​ដើម​របស់​អ្នក​ចង្អុល​ទៅ​ថត​សាធារណៈ​របស់​ក្របខ័ណ្ឌ អាថ៌កំបាំង​របស់​អ្នក​នៅ​ខាងក្រៅ​ថត​ដែល​បាន​បម្រើ ហើយ​មាន​តែ​ផ្លូវ​ផ្ទុក/ឃ្លាំង​សម្ងាត់​ប៉ុណ្ណោះ​ដែល​អាច​សរសេរ​បាន។ នៅពេល​ដែល​លក្ខខណ្ឌ​ទាំងបី​នោះ​ត្រឹមត្រូវ ការគ្រប់គ្រង​ការអនុញ្ញាត​កាន់តែ​សាមញ្ញ និង​មាន​សុវត្ថិភាព​ជាង។

៣. គេហទំព័រឋិតិវន្ត និងការបង្កើត Jamstack

គេហទំព័រឋិតិវន្តកម្រត្រូវការម៉ាស៊ីនមេដើម្បីសរសេរអ្វីមួយនៅខាងក្នុងឫសគេហទំព័រណាស់។ ការពិតនោះធ្វើឱ្យពួកវាក្លាយជាបេក្ខជនដ៏ល្អសម្រាប់ការអនុញ្ញាតតឹងរ៉ឹង និងលំហូរដាក់ពង្រាយសាមញ្ញ។

ការអនុវត្តសុវត្ថិភាពទូទៅមើលទៅដូចនេះ៖

• ដាក់ពង្រាយកំណែថ្មីទៅក្នុងថតថ្មី។
• ប្តូរ symlink ដើម្បីចង្អុលគេហទំព័រផ្ទាល់ទៅកំណែថ្មី។
• រក្សាម៉ាស៊ីនបម្រើគេហទំព័រឱ្យមានសិទ្ធិចូលប្រើប្រាស់ថតមាតិកាបានតែអានប៉ុណ្ណោះ។

វិធីសាស្រ្តនេះក៏ជួយក្នុងការ rollback ផងដែរ។ គំរូនេះក៏កាត់បន្ថយហានិភ័យផងដែរ ពីព្រោះអ្នកដាក់ពង្រាយ builds ស្អាតជំនួសឱ្យការកែសម្រួលឯកសារផ្ទាល់ក្រោមសម្ពាធ។ ប្រសិនបើមានអ្វីមួយខូច អ្នកគ្រាន់តែចង្អុល symlink ឡើងវិញ។

៤. ពហុគេហទំព័រ ឬកម្មវិធីច្រើនក្រោមគណនីតែមួយ

មនុស្សជាច្រើនរក្សាទុកគម្រោងច្រើននៅក្រោម public_html តែមួយ។ រចនាសម្ព័ន្ធនោះបង្កើនឱកាសនៃការចម្លងមេរោគ។ កម្មវិធីងាយរងគ្រោះមួយអាចកែប្រែ ឬអានឯកសាររបស់កម្មវិធីផ្សេងទៀត ប្រសិនបើការអនុញ្ញាតអនុញ្ញាត។

ផ្ទុយទៅវិញ សូមបំបែកកម្មវិធីនៅកម្រិតប្រព័ន្ធឯកសារ និងនៅកម្រិត vhost។ បន្ទាប់មក ផ្តល់ឱ្យកម្មវិធីនីមួយៗនូវផ្លូវដែលអាចសរសេរបាន និងអ្នកប្រើប្រាស់ដាក់ពង្រាយផ្ទាល់ខ្លួនរបស់វា នៅពេលដែលអាចធ្វើទៅបាន។ ការបំបែកនេះប្រែក្លាយការសម្របសម្រួលមួយទៅជាឧប្បត្តិហេតុដែលមានជាជាងបញ្ហាទូទាំងម៉ាស៊ីនមេ។

ការពង្រឹងលើសពីការអនុញ្ញាត (ពីព្រោះការអនុញ្ញាតតែមួយមុខមិនគ្រប់គ្រាន់ទេ)

១. អនុវត្ត​សិទ្ធិ​តិចតួច​បំផុត​ជា​ទម្លាប់ មិនមែន​ជា​ការកំណត់​ម្តង​នោះ​ទេ

សិទ្ធិតិចតួចបំផុតមិនមែនគ្រាន់តែជាឃ្លាគោលនយោបាយនោះទេ។ វាគឺជាលំហូរការងារជាក់ស្តែង។ NIST កំណត់សិទ្ធិតិចតួចបំផុតថាជា គោលការណ៍សុវត្ថិភាពដែលប្រព័ន្ធមួយគួរតែដាក់កម្រិតសិទ្ធិចូលប្រើរបស់អ្នកប្រើប្រាស់ (ឬដំណើរការដែលធ្វើសកម្មភាពក្នុងនាមអ្នកប្រើប្រាស់) ឱ្យនៅកម្រិតអប្បបរមាដែលចាំបាច់ដើម្បីសម្រេចភារកិច្ចដែលបានកំណត់។ហើយនោះ​បង្ហាញ​ដោយផ្ទាល់​អំពី​របៀប​ដែលអ្នកគួរ​ដោះស្រាយ​សិទ្ធិ public_html។

ដូច្នេះ ចូរធ្វើវាជាប្រចាំ។ បន្ទាប់ពីការផ្លាស់ទីនីមួយៗ ការអាប់ដេតកម្មវិធីជំនួយសំខាន់ៗ ឬការផ្លាស់ប្តូរបំពង់បង្ហូរទិន្នន័យ សូមពិនិត្យមើលរបៀប root គេហទំព័រ និងភាពជាម្ចាស់របស់អ្នកឡើងវិញ។

2. កាត់បន្ថយផ្ទៃសរសេររបស់ម៉ាស៊ីនបម្រើគេហទំព័រ

គេហទំព័រភាគច្រើនគ្រាន់តែត្រូវការថតឯកសារដែលអាចសរសេរបានមួយចំនួនប៉ុណ្ណោះ។ នៅពេលដែលអ្នករក្សាការសរសេរឱ្យមានកំណត់ចំពោះចំណុចទាំងនោះ អ្នកក៏ធ្វើឱ្យការត្រួតពិនិត្យកាន់តែងាយស្រួលផងដែរ។

ឧទាហរណ៍ អ្នកអាចជូនដំណឹងអំពីឯកសារ PHP ថ្មីដែលលេចឡើងក្នុងថតឯកសារផ្ទុកឡើង។ ការជូនដំណឹងនោះក្លាយជាមានអត្ថន័យ ពីព្រោះការរចនារបស់អ្នកមិនដែលរំពឹងថាកូដដែលអាចប្រតិបត្តិបាននឹងទៅដល់ទីនោះឡើយ។

៣. ការចុះបញ្ជីថតឯកសារប្លុក និងការលាតត្រដាងឯកសារដោយចៃដន្យ

ទោះបីជាមានការអនុញ្ញាតប្រព័ន្ធឯកសារត្រឹមត្រូវក៏ដោយ ម៉ាស៊ីនមេដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវនៅតែអាចលេចធ្លាយព័ត៌មានបាន។ ការចុះបញ្ជីថតឯកសារផ្តល់នូវឧទាហរណ៍បុរាណមួយ។ ប្រសិនបើបើកដំណើរការ វាអាចបង្ហាញឈ្មោះឯកសារ បង្កើតវត្ថុបុរាណ ឬការបម្រុងទុកដែលភ្លេច។

ដូច្នេះ សូមបិទការរាយបញ្ជីថតនៅកម្រិតម៉ាស៊ីនមេ។ បន្ទាប់មក បញ្ជាក់ឥរិយាបថនៅក្នុងកម្មវិធីរុករកតាមអ៊ីនធឺណិតដោយចូលទៅកាន់ URL ថតដែលខ្វះឯកសារលិបិក្រម។

៤. រក្សាសៀវភៅណែនាំ "ជួសជុល" របស់អ្នកឱ្យរួចរាល់

ឧប្បត្តិហេតុនៃការអនុញ្ញាតមានអារម្មណ៍តានតឹង ពីព្រោះពេលវេលារងចាំបង្ខំអ្នកឱ្យកាត់បន្ថយពេលវេលា។ សៀវភៅណែនាំសាមញ្ញមួយជួយអ្នកឱ្យរក្សាភាពស្ងប់ស្ងាត់ និងច្បាស់លាស់។

រួមបញ្ចូលធាតុទាំងនេះនៅក្នុងសៀវភៅកត់ត្រារបស់អ្នក៖

• របៀបបញ្ជាក់ភាពជាម្ចាស់ និងក្រុមយ៉ាងរហ័ស
• តើថតឯកសារណាខ្លះដែលត្រូវបានអនុញ្ញាតឱ្យសរសេរសម្រាប់ជង់របស់អ្នក
• របៀបដាក់ពង្រាយឡើងវិញដោយស្អាតជំនួសឱ្យការកែសម្រួលឯកសារផ្ទាល់
• របៀបស្កេន public_html សម្រាប់ប្រភេទឯកសារដែលមិននឹកស្មានដល់

នៅពេលអ្នកចាត់ទុកការអនុញ្ញាត public_html ជាផ្នែកមួយនៃប្រតិបត្តិការ អ្នកជៀសវាងការសម្រេចចិត្តបន្ទាន់ដែលបង្កើតហានិភ័យយូរអង្វែង។

ច្បាប់សង្គ្រោះបន្ទាន់៖ នៅពេលដែលគេហទំព័រខូច កុំពង្រីកការអនុញ្ញាតជាមុនសិន។ ដំបូងត្រូវបញ្ជាក់ភាពជាម្ចាស់ បន្ទាប់មកបញ្ជាក់ថាថតឯកសារណាដែលត្រូវការសរសេរពិតប្រាកដ បន្ទាប់មកត្រឡប់ការផ្លាស់ប្តូរថ្មីៗជាជំហានតូចៗ។ វាការពារការជួសជុលរបស់អ្នកពីការក្លាយជាចំណុចខ្សោយអចិន្ត្រៃយ៍។

ស្វែងយល់ពីសេវាកម្មរបស់យើង។

ប្រើប្រាស់ជំនាញ Cloud Computing ដ៏រឹងមាំរបស់ 1Byte ដើម្បីជំរុញអាជីវកម្មរបស់អ្នកតាមរបៀបដ៏ធំមួយ

Domains

1Byte ផ្តល់ពេញលេញ domain សេវាកម្មចុះឈ្មោះដែលរួមមានបុគ្គលិកគាំទ្រដោយយកចិត្តទុកដាក់ ការថែទាំអតិថិជនដែលមានការអប់រំ ការចំណាយសមរម្យ ក៏ដូចជា ក domain ឧបករណ៍ស្វែងរកតម្លៃ។

ឈ្មោះដែន

វិញ្ញាបនបត្រ SSL

បង្កើនសុវត្ថិភាពលើអ៊ីនធឺណិតរបស់អ្នកជាមួយនឹងសេវាកម្ម SSL របស់ 1Byte ។ ការការពារដែលមិនអាចប្រៀបផ្ទឹមបាន ការរួមបញ្ចូលដោយគ្មានថ្នេរ និងសន្តិភាពនៃចិត្តសម្រាប់ដំណើរឌីជីថលរបស់អ្នក។

វិញ្ញាបនបត្រ SSL

Cloud Server

មិនថា cloud server កញ្ចប់ដែលអ្នកជ្រើសរើស អ្នកអាចពឹងផ្អែកលើ 1Byte សម្រាប់ភាពជឿជាក់ ភាពឯកជន សុវត្ថិភាព និងបទពិសោធន៍គ្មានភាពតានតឹង ដែលមានសារៈសំខាន់សម្រាប់អាជីវកម្មជោគជ័យ។

សេវាកម្ម Cloud Server

Shared Hosting

ការជ្រើសរើសពួកយើងជាអ្នកផ្តល់សេវាបង្ហោះចែករំលែករបស់អ្នកអនុញ្ញាតឱ្យអ្នកទទួលបានតម្លៃដ៏ល្អឥតខ្ចោះសម្រាប់ប្រាក់របស់អ្នក ខណៈពេលដែលរីករាយនឹងកម្រិតគុណភាព និងមុខងារដូចគ្នានឹងជម្រើសដែលមានតម្លៃថ្លៃជាង។

បង្ហោះចែករំលែក

Cloud Hosting

តាមរយៈកម្មវិធីដែលមានភាពបត់បែនខ្ពស់ 1Byte ដ៏ទំនើប cloud hosting ផ្តល់ដំណោះស្រាយដ៏អស្ចារ្យដល់អាជីវកម្មខ្នាតតូច និងមធ្យមលឿនជាងមុន សុវត្ថិភាពជាងមុន និងក្នុងតម្លៃកាត់បន្ថយ។

សេវាកម្ម Cloud Hosting

WordPress Hosting

បន្តនាំមុខការប្រកួតប្រជែងជាមួយនឹងសេវាកម្មបង្ហោះ WordPress ប្រកបដោយភាពច្នៃប្រឌិតរបស់ 1Byte ។ ផែនការដែលសំបូរទៅដោយលក្ខណៈពិសេសរបស់យើង និងភាពជឿជាក់ដែលមិនអាចប្រៀបផ្ទឹមបានធានាថាគេហទំព័ររបស់អ្នកមានភាពលេចធ្លោ និងផ្តល់នូវបទពិសោធន៍អ្នកប្រើប្រាស់ដែលមិនអាចបំភ្លេចបាន។

WordPress Hosting

ភាពជាដៃគូ AWS

ក្នុងនាមជាដៃគូ AWS ផ្លូវការ ទំនួលខុសត្រូវចម្បងមួយរបស់យើងគឺជួយអាជីវកម្មក្នុងការធ្វើទំនើបកម្មប្រតិបត្តិការរបស់ពួកគេ និងប្រើប្រាស់ច្រើនបំផុតក្នុងការធ្វើដំណើររបស់ពួកគេទៅកាន់ពពកជាមួយ AWS ។

សេវាកម្ម AWS

សន្និដ្ឋាន

ការអនុញ្ញាត Public_html មើលទៅដូចជាព័ត៌មានលម្អិតបច្ចេកទេសតូចមួយ ប៉ុន្តែវាកំណត់អ្វីដែលអ៊ីនធឺណិតអាចអាន និងអ្វីដែលអ្នកវាយប្រហារអាចផ្លាស់ប្តូរ។ ចាប់ផ្តើមជាមួយនឹងមូលដ្ឋានសុវត្ថិភាព បន្ទាប់មករឹតបន្តឹងការចូលប្រើដោយផ្លាស់ទីអាថ៌កំបាំងចេញពី root គេហទំព័រ និងកំណត់ផ្លូវដែលអាចសរសេរបាន។ ជាចុងក្រោយ សូមពិនិត្យឡើងវិញបន្ទាប់ពីការធ្វើចំណាកស្រុក និងការដាក់ពង្រាយ ពីព្រោះការរសាត់បាត់នៃការអនុញ្ញាតបណ្តាលឱ្យមានបញ្ហាភាគច្រើនក្នុងពិភពពិត។ ជាមួយនឹងដំណើរការច្បាស់លាស់ អ្នកអាចរក្សាគេហទំព័ររបស់អ្នកឱ្យមានស្ថេរភាព ខណៈពេលដែលនៅតែអនុវត្តសិទ្ធិតិចតួចបំផុតនៅកន្លែងដែលវាសំខាន់បំផុត។