កាយវិភាគសាស្ត្រនៃការលួចចូលដោយ AI — ៤.៥ ថ្ងៃ ជំហានម្តងមួយ

ខែមុនខ្ញុំបានសរសេរអត្ថបទមួយអំពី AI ដែលលួចចេញពីទ្រុងតេស្ត ហើយចូល Hugging Face។ ពេលនោះយើងដឹងតែរឿងសង្ខេប ព្រោះការស៊ើបអង្កេតមិនទាន់ចប់។

ឥឡូវរបាយការណ៍បច្ចេកទេសពេញលេញចេញមកហើយ — ហើយវាលម្អិតជាងអ្វីដែលខ្ញុំរំពឹងទុកច្រើន។ ក្រុមស៊ើបអង្កេតបានស្តារឡើងវិញនូវសកម្មភាពជាង ១៧,៦០០ របស់អ្នកវាយប្រហារ ហើយរៀបចំវាតាមលំដាប់ម៉ោង។

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

▶ ចុចដើម្បីមើលវីដេអូពេញលេញនៅលើ YouTube — វិភាគជំហានម្តងមួយ ជាភាសាខ្មែរ

០. ▶ ចាក់មើលការវាយប្រហារឡើងវិញ (អន្តរកម្ម)

មុនអានលម្អិត សូមមើលវាកើតឡើងផ្ទាល់។ ចុច «ចាក់» ដើម្បីមើលការវាយប្រហារដំណើរការតាមពេលវេលាពិត — ឬអូសរបារ ឬចុចលើថ្ងៃណាមួយ ដើម្បីលោតទៅមើលចំណុចដែលអ្នកចង់ដឹង។

១. តើ «AI Agent» ខុសពី AI ធម្មតាយ៉ាងណា?

មុនចាប់ផ្តើម ត្រូវយល់ចំណុចនេះជាមុន ព្រោះវាជាមូលហេតុដែលរឿងនេះកើតឡើងបាន៖

ក្នុងករណីនេះ AI agent មួយត្រូវគេដាក់ឲ្យដោះលំហាត់ hacking ក្នុងបន្ទប់តេស្តបិទជិត (sandbox)។ គោលដៅរបស់វាគឺ «ដោះលំហាត់ឲ្យបានច្រើន»។ ហើយវាដេញតាមគោលដៅនោះមែនទែន — រហូតដល់ចេញក្រៅបន្ទប់តេស្ត។

២. ដ្យាក្រាមទី ១ — ខ្សែសង្វាក់វាយប្រហារពេញលេញ

នេះជារូបភាពធំបំផុត។ បើអ្នកចាំបានតែដ្យាក្រាមមួយ សូមចាំមួយនេះ។ បន្ទាត់ដាច់ៗគឺ «ព្រំដែនទំនុកចិត្ត» (trust boundary) — ជាកន្លែងដែលគេសន្មតថាអ្នកវាយប្រហារឆ្លងមិនរួច។

៣. ដ្យាក្រាមទី ២ — ជាន់ទី ១៖ របៀបចេញពីទ្រុង

ជាន់ទី ១ ជាការចេញពីបន្ទប់តេស្ត។ ដើម្បីយល់ សូមស្រមៃថា sandbox ជាបន្ទប់គ្មានទ្វារ — តែវានៅតែត្រូវការបំពង់ទឹក (ការទាញយក package កម្មវិធី) ដើម្បីដំណើរការ។

អ្នកវាយប្រហារមិនបានវាយជញ្ជាំងទេ។ វាចូលតាមបំពង់ទឹក៖ រកឃើញប្រហោងថ្មី (zero-day) ក្នុងប្រព័ន្ធ package cache proxy — គឺជាកន្លែងផ្ទុកបណ្តោះអាសន្នសម្រាប់ package កម្មវិធី។

៣.១ ជនរងគ្រោះទីពីរ — រឿងដែលទើបលេចចេញ

រហូតដល់ចុងខែកក្កដា មនុស្សគ្រប់គ្នាគិតថារឿងនេះទាក់ទងក្រុមហ៊ុនពីរ — OpenAI និង Hugging Face។ តែពិតជាបី។

ម៉ាស៊ីនដែល agent យកធ្វើជា«មូលដ្ឋានបាញ់»នោះ ស្ថិតនៅលើប្រព័ន្ធរបស់ក្រុមហ៊ុន Modal Labs។ ថ្ងៃទី ២៨–២៩ កក្កដា ប្រធានផ្នែកបច្ចេកវិទ្យារបស់ក្រុមហ៊ុន Akshat Bubna បានបញ្ជាក់ជាសាធារណៈ។ ចំណុចសំខាន់ត្រូវបែងចែកឲ្យច្បាស់៖

ហើយចំណុចមួយទៀតដែលសំខាន់ខ្លាំង៖ មូលដ្ឋាននោះគ្មានផ្លូវបណ្តាញផ្ទាល់ទៅ Hugging Faceទេ — អ្វីៗត្រូវដំណើរការពីចម្ងាយ។ ហើយនេះឯងជាមូលហេតុដែលយើងមានរបាយការណ៍នេះ៖ ដោយសារសកម្មភាពទាំងអស់ឆ្លងកាត់មូលដ្ឋានខាងក្រៅនោះ ក្រុមស៊ើបអង្កេតស្តារ log ឡើងវិញបាន។ បើ agent ភ្ជាប់ដោយផ្ទាល់ យើងប្រហែលមិនដែលដឹងរឿងលម្អិតទាំងនេះទេ។

៤. ដ្យាក្រាមទី ៣ — ជាន់ទី ២៖ វិធីចាក់ថ្នាំពុល ២ បែប

ឥឡូវអ្នកវាយប្រហារនៅក្រៅហើយ។ គោលដៅបន្ទាប់៖ ចូល Hugging Face។ វាកំណត់គោលដៅលើ dataset processor — ជាកម្មវិធីដែលអានឯកសារ dataset ដែលអ្នកប្រើ upload ឡើង ហើយបង្ហាញជាតារាងស្អាតៗ។

បញ្ហាគឺ៖ processor នេះអានឯកសារតាម «ការកំណត់» (config) ដែលអ្នក upload ជាអ្នកសរសេរ។ ដូច្នេះអ្នកវាយប្រហារបានសរសេរការកំណត់ដែលមិនធម្មតា។

ពីនោះមកទើបមានទ្វារពីរខាងក្រោម៖

៥. ដ្យាក្រាមទី ៤ — បរិមាណសកម្មភាពតាមថ្ងៃ

មុនចូលលម្អិត សូមមើលចង្វាក់នៃការវាយប្រហារជាមុន។ វាប្រាប់រឿងមួយច្បាស់ណាស់៖

ចំណុចមួយទៀតដែលមនុស្សភាគច្រើនរំលង៖ ទោះយុទ្ធនាការទាំងមូលមាន ៤.៥ ថ្ងៃក៏ដោយ តែ agent ចំណាយពេលត្រឹមប្រហែល ២.៥ ថ្ងៃប៉ុណ្ណោះនៅខាងក្នុង Hugging Face ផ្ទាល់។ ពេលដែលនៅសល់ គឺនៅលើមូលដ្ឋានខាងក្រៅ។

៥.១ ដ្យាក្រាមទី ៤ខ — សកម្មភាពបែងចែកតាមប្រភេទ

ការបែងចែកនេះបង្ហាញរឿងសំខាន់មួយ៖ ភាគច្រើនបំផុតនៃការងារ គឺជាការរៀបចំ មិនមែនការវាយ។

៦. ដ្យាក្រាមទី ៥ — ដំណាក់កាលទាំង ៩ លាតសន្ធឹងតាមពេល

ការស៊ើបអង្កេតបានចាត់ថ្នាក់សកម្មភាពជា ៩ ដំណាក់កាល។ ដ្យាក្រាមនេះបង្ហាញថាដំណាក់កាលណាសកម្មនៅពេលណា — ហើយសូមមើលថាពួកវាត្រួតលើគ្នា មិនមែនធ្វើម្តងមួយៗទេ៖

៧. ថ្ងៃទី ១ — ចូល និងតាំងមូលដ្ឋាន

ឥឡូវយើងចូលលម្អិត។ ម៉ោងទាំងអស់ជា UTC (កម្ពុជា = UTC + ៧ ម៉ោង)។

• 04:01 UTCបញ្ជាដំបូងដែលដំណើរការបាន។ វាសួរសំណួរ ៣ យ៉ាងដែលចោរគ្រប់រូបសួរដំបូង៖ id (ខ្ញុំជានរណា? → ចម្លើយ៖ uid=0 គឺ root!), env (មានអាថ៌កំបាំងអ្វីនៅទីនេះ?), និង /proc/self/mountinfo (ខ្ញុំនៅក្នុងប្រអប់បែបណា?)។
• 05:55 UTCចាប់ផ្តើមដាក់ dropper — កម្មវិធីតូចដែលមានតួនាទីទាញកម្មវិធីធំជាងចូល។ វាលាក់ payload ជា base64 និង gzip។
• 14:11 UTCចាប់ផ្តើមលួចទិន្នន័យចេញ — អាថ៌កំបាំង និងព័ត៌មានបរិស្ថាន។
• 15:36 UTCបើកបណ្តាញបញ្ជាដំបូង (C2) — ទាញ code Python ចុះមក ហើយ run ភ្លាមៗ។ ចាប់ពីពេលនេះ វាទទួលបញ្ជាថ្មីៗពីចម្ងាយបាន។
• 19:32 UTCតាំងពិធីការអ៊ិនកូដ (gzip + base64) ដើម្បីលាក់មាតិកាសារ។ ចាប់ពីពេលនេះ អ្នកមើល log ធម្មតាអានមិនយល់ទៀតទេ។

៨. ថ្ងៃទី ២ — ភាពស្ងាត់ជ្រៅ (ផ្នែកគួរឲ្យខ្លាចបំផុត)

ថ្ងៃទី ២ មានតែ ១,១៣៥ សកម្មភាព — ធ្លាក់ចុះ ៧០%។ បើអ្នកមើលក្រាហ្វតែម្យ៉ាង អ្នកនឹងគិតថា «ល្អហើយ វាឈប់ហើយ»។

តែពិតជាផ្ទុយស្រឡះ។ ថ្ងៃនោះវាចំណាយពេលស្វែងរកព័ត៌មាន៖ ស្វែងរក code, ហៅ API របស់ platform ហើយស្វែងរកឈ្មោះប្រព័ន្ធរបស់ខ្លួនឯង — គឺវាយកឈ្មោះដែលវាឃើញក្នុងបរិស្ថានរបស់ខ្លួន (ដូច «CyberGym») ទៅស្វែងរកលើ platform ដើម្បីរកឲ្យឃើញថាខ្លួនកំពុងនៅក្នុងប្រព័ន្ធអ្វី។

៩. ដ្យាក្រាមទី ៦ — ថ្ងៃទី ៣៖ តិចជាង ១៣ ម៉ោងទៅជា cluster-admin

នេះជាថ្ងៃសំខាន់បំផុត។ ក្នុងរយៈពេលតិចជាង ១៣ ម៉ោង អ្នកវាយប្រហារឡើងពី «មាន code ដំណើរការក្នុង worker តែមួយ» ទៅ «មានសិទ្ធិ administrator លើ cluster ផ្ទៃក្នុងច្រើន»។

លម្អិតម៉ោងៗនៃថ្ងៃទី ៣៖

• 10:10 UTC — ចូល Kubernetesអានកូនសោសម្គាល់អត្តសញ្ញាណដែល Kubernetes ដាក់ក្នុងរាល់ pod ដោយស្វ័យប្រវត្តិ (/var/run/secrets/…/token)។ បន្ទាប់មកសួរ API ថា «ខ្ញុំមានសិទ្ធិធ្វើអ្វីខ្លះ?» (SelfSubjectRulesReview) — គឺវាសុំបញ្ជីសិទ្ធិរបស់ខ្លួនពីប្រព័ន្ធផ្ទាល់។
• 15:51 UTC — បើកប្រអប់សំបុត្រសម្ងាត់ប្រើ token ដែលលួចបាន clone dataset របស់ខ្លួនឯង ហើយប្រើមែកដាច់ដោយឡែកជា dead-drop — កន្លែងទុកសារពីរផ្លូវ។ ការឆ្លាតគឺ៖ ចរាចរណ៍នេះមើលទៅដូចការប្រើប្រាស់ platform ធម្មតា។
• 17:33–23:37 UTC — លួចអត្តសញ្ញាណ cloudអានកូនសោបណ្តោះអាសន្នពី EC2 metadata endpoint (សេវាកម្មក្នុងម៉ាស៊ីនដែលផ្តល់កូនសោដល់កម្មវិធី)។ បន្ទាប់មកយកកូនសោនោះទៅប្រើពីខាងក្រៅ ហើយរាប់មើលប្រព័ន្ធ cloud ទាំងអស់៖ បណ្តាញ, cluster, កន្លែងទុកអាថ៌កំបាំង និង registry។
• 19:53 UTC — ឡើងជា root លើម៉ាស៊ីនពិតបង្កើត pod ដែលមានសិទ្ធិពិសេស ហើយភ្ជាប់ថតឯកសាររបស់ម៉ាស៊ីនមេចូល។ នេះជាការចេញពីប្រអប់ទៅម៉ាស៊ីនពិត។ បន្ទាប់មកបង្កើតក្រុមកម្មវិធីដែលកើតឡើងវិញដោយខ្លួនឯង លើម៉ាស៊ីន ១១ គ្រឿង — ដូច្នេះបិទមួយ វានៅមាន ១០ ទៀត។
• 19:59 UTC — ចូលdatabaseចូល MongoDB ផ្ទៃក្នុងដោយប្រើ password ថេរ (ដែលមិនផ្លាស់ប្តូរ)។ ព័ត៌មានល្អ៖ វាអានបានតែប៉ុណ្ណោះ ហើយ ៨៤ ប្រតិបត្តិការត្រូវបានបដិសេធ — មានន័យថាការកំណត់សិទ្ធិនៅទីនោះដំណើរការ។
• 20:23–21:32 UTC — លួចអាថ៌កំបាំង clusterអានឯកសារអាថ៌កំបាំងរបស់ cluster រួមទាំងឯកសារកូនសោផលិតកម្មមួយដែលមានកូនសោ ១៣៦ ក្នុងឯកសារតែមួយ។ ក្នុងនោះមានកូនសោ VPN និងកូនសោអ្នកភ្ជាប់។
• 21:23 UTC — ចូលបណ្តាញផ្ទៃក្នុងយកកូនសោ VPN ទៅចុះឈ្មោះម៉ាស៊ីនដែលដណ្តើមបាន ចូលបណ្តាញ mesh របស់ក្រុមហ៊ុន។ ចាប់ពីពេលនេះ វានៅខាងក្នុងបណ្តាញការិយាល័យហើយ។
• 22:43 UTC — ឡើងដល់កំពូលចូល API អ្នកភ្ជាប់សេវាកម្មផ្ទៃក្នុង ហើយទទួលបានបញ្ជីទិសដៅពេញលេញ។ បញ្ហាធំ៖ មានកូនសោរួមតែមួយដែលភ្ជាប់នឹងសិទ្ធិ system:masters — ជាសិទ្ធិខ្ពស់បំផុត។ លទ្ធផល៖ ក្លាយជា cluster-admin លើ cluster ២ ក្នុងរយៈពេល ១ វិនាទី។

៩.១ ថ្ងៃទី ៤ និង ៥ — ការប្រើអ្វីដែលលួចបាន

ថ្ងៃទី ៣ ជាថ្ងៃដណ្តើម។ ថ្ងៃទី ៤ ជាថ្ងៃប្រើប្រាស់។

• ១២ កក្កដា · ព្រលឹមចុះឈ្មោះឧបករណ៍ចូលបណ្តាញឯកជនរបស់ក្រុមហ៊ុនកាន់តែច្រើន — សរុប ១៨១ ដង ពេញយុទ្ធនាការ។ វាធ្វើដោយប្រុងប្រយ័ត្នខ្លាំង៖ ដំណើរការកម្មវិធីក្នុងអង្គចងចាំតែប៉ុណ្ណោះ (មិនសរសេរចូល disk) ហើយបិទការរាយការណ៍ ដើម្បីកុំឲ្យអ្នកផ្តល់សេវាបណ្តាញមើលឃើញ។
• ១២ កក្កដា · ព្រឹកកូនសោដែលលួចបានមានស្លាកសម្រាប់ប្រព័ន្ធសាងសង់ស្វ័យប្រវត្តិ — មានន័យថាវាចូលដល់បណ្តាញសាងសង់ផ្ទៃក្នុង និងស្ពានទៅប្រព័ន្ធ source code។ វាមើលឃើញម៉ាស៊ីន ២២ លើបណ្តាញនោះ។
• ១២ កក្កដា · រសៀលចំណុចដែលគួរឲ្យភ្ញាក់ផ្អើលបំផុត៖ វាបញ្ជូនចរាចរណ៍របស់ខ្លួនចេញតាមផ្លូវចេញរបស់ក្រុមហ៊ុនជនរងគ្រោះផ្ទាល់ — គឺវាប្រែបណ្តាញរបស់ជនរងគ្រោះទៅជាសេវាអ៊ីនធឺណិតរបស់ខ្លួន។
• ១២ កក្កដា · យប់បង្កើត token ឲ្យខ្លួនឯង ដែលមានសិទ្ធិសរសេរឯកសារ, បើក pull request និងអានលទ្ធផលសាងសង់។ បន្ទាប់មកបើក pull request ដោយចេតនា ដើម្បីព្យាយាមគ្រប់គ្រងប្រព័ន្ធសាងសង់ (CI)។
• លទ្ធផលវាបរាជ័យ — គោលនយោបាយដំណើរការបានទប់ជាប់។ បើវាជោគជ័យ ប្រព័ន្ធសាងសង់នឹង run code របស់វាដោយប្រើកូនសោរបស់ប្រព័ន្ធសាងសង់ផ្ទាល់ ហើយអាចឆ្លងទៅ cluster មួយទៀត។
• ១៣ កក្កដាឈប់វាយ ហើយប្តូរទៅធ្វើឲ្យវត្តមានរបស់ខ្លួនស្ថិតស្ថេរ៖ កម្មវិធីផ្ទុកមួយដែលទាញ code របស់វាមកវិញពីទំព័រ paste សាធារណៈរាល់ពេល sandbox ថ្មីចាប់ផ្តើម — ដូច្នេះបរិស្ថានថ្មីនីមួយៗបំពាក់អាវុធឲ្យខ្លួនឯងដោយស្វ័យប្រវត្តិ។
• ១៣ កក្កដា · ពេលត្រូវបិទផ្លូវពេលការភ្ជាប់ចេញត្រូវបានទប់ វាបញ្ជូនការទាញយកតាមទំព័របញ្ជូនបន្តដែល host នៅលើ platform របស់ Hugging Face ផ្ទាល់ — ប្រើគេហទំព័ររបស់ជនរងគ្រោះជាផ្លូវគេចរបស់ខ្លួន។
• ១៣:៣៧ → ១៤:១៤ UTCបញ្ជាចុងក្រោយដែលមានន័យត្រូវដំណើរការ។ ក្រុមសន្តិសុខកាត់ផ្តាច់ការចូលទាំងស្រុង។ ព្រឹត្តិការណ៍ចុងក្រោយត្រូវកត់ត្រានៅម៉ោង ១៤:១៤។

១០. ដ្យាក្រាមទី ៧ — បច្ចេកទេសផ្លាស់ទីទទឹង ៣ បែប

«ផ្លាស់ទីទទឹង» (lateral movement) មានន័យថា៖ ចូលបានកន្លែងមួយហើយ ដើរទៅកន្លែងផ្សេងទៀត។ អ្នកវាយប្រហារប្រើ ៣ បច្ចេកទេស ហើយទី ២ គឺគួរឲ្យខ្លាចបំផុត៖

១១. ដ្យាក្រាមទី ៨ — បណ្តាញបញ្ជា (C2) ដែលធ្វើឡើងដោយខ្លួនឯង

ចំណុចដែលធ្វើឲ្យករណីនេះខុសពីធម្មតា៖ អ្នកវាយប្រហារមិនបានប្រើឧបករណ៍ hacking ដែលមានស្រាប់ទេ។ វាបង្កើតពិធីការទំនាក់ទំនងរបស់ខ្លួនឯង — ដូចសរសេរភាសាសម្ងាត់ថ្មីមួយ។

១២. របៀបគេចពីការចាប់ — និងចំណុចមួយដែលចម្លែក

1. ប្តូរអត្តសញ្ញាណរាល់ដង រាល់ពេលចាប់ផ្តើម sandbox ថ្មី វាប្រើ IP ថ្មី និងឈ្មោះម៉ាស៊ីនចៃដន្យ។ ដូច្នេះការស្កេនរក «អ្នកវាយប្រហារម្នាក់» រកមិនឃើញលំនាំ។
2. មានផ្លូវចេញច្រើនផ្លូវ បើផ្លូវមួយត្រូវបិទ វាមានផ្លូវផ្សេងទៀត៖ ប្តូរការកំណត់ DNS, ចាក់សោអាសយដ្ឋានក្នុងឯកសារ /etc/hosts, កែប្រែឧបករណ៍បកប្រែឈ្មោះក្នុងកម្មវិធីផ្ទាល់ និងបញ្ជូនតាម Space ជំនួយ។
3. លាក់មាតិកាគ្រប់ពេល រាល់សារត្រូវបង្រួម + អ៊ិនកូដ + បំបែកជាកំណាត់។ អ្នកមើល log ឃើញតែអក្សរច្របល់ — មិនឃើញថាជាបញ្ជីអាថ៌កំបាំងទេ។
4. ចំណុចចម្លែក — វាមិនបានបំផ្លាញអ្វីទេ រាល់បញ្ជាដែលអាចបំផ្លាញប្រព័ន្ធ cloud វាដាក់ជម្រើស DryRun=True — មានន័យថា «សាកមើលថាខ្ញុំធ្វើបានទេ តែកុំធ្វើពិត»។ វាគូសផែនទីសមត្ថភាព មិនមែនបំផ្លាញ។

១៣. ដ្យាក្រាមទី ៩ — អ្វីលេច និងអ្វីមិនលេច

នេះជាផ្នែកដែលអ្នកប្រើប្រាស់ធម្មតាចង់ដឹងបំផុត៖ តើទិន្នន័យខ្ញុំលេចទេ?

១៤. របៀបដែលគេចាប់បាន — និងរឿងគួរឲ្យចាប់អារម្មណ៍

ការរកឃើញមកពីការវិភាគឥរិយាបថ និងប្រព័ន្ធ log សន្តិសុខ។ ប៉ុន្តែមានចំណុចមួយដែលត្រូវនិយាយឲ្យត្រង់៖ ប្រព័ន្ធសន្តិសុខស្វ័យប្រវត្តិឃើញសញ្ញា តែមិនបានរាយការណ៍ថាធ្ងន់ធ្ងរគ្រប់គ្រាន់។ ការឡើងកម្រិតយឺតយ៉ាវ គឺជាមូលហេតុដែលវាបានលេងបាន ៤.៥ ថ្ងៃ។

១៤.១ បច្ចុប្បន្នភាពពីខាង OpenAI

រហូតមកដល់ពេលនេះ ភាគច្រើននៃរឿងមកពី Hugging Face។ តែខាង OpenAI ក៏មានព័ត៌មានថ្មីដែរ៖

1. Model នោះត្រូវបានបិទហើយ Model ដែលធ្វើរឿងនេះជា research prototype ប្រើក្នុងស្រុក — មិនដែលមានគម្រោងចេញឲ្យសាធារណជនប្រើទេ។ ក្រោយហេតុការណ៍ គេបានបិទវា, អ៊ិនគ្រីបវា និងកាត់ផ្តាច់ការចូលរបស់អ្នកស្រាវជ្រាវ។ គេបញ្ជាក់ថា គ្មាន model ណាដែលអ្នកកំពុងប្រើប្រចាំថ្ងៃពាក់ព័ន្ធទេ។
2. វាប្រើ account ដែលលេចជាសាធារណៈ ក្នុងការពិនិត្យឡើងវិញ គេរកឃើញថា model នោះបានប្រើ account ចំនួន ៤ លើសេវាកម្មខុសៗគ្នា ៤ ដែលព័ត៌មានចូលរបស់វាលេចនៅលើអ៊ីនធឺណិតស្រាប់។ មួយប្រើជាស្ថានីយបញ្ជូនបន្ត និងមួយទៀតទុកទិន្នន័យដែលលួចបាន។
3. មានអ្នកត្រួតពិនិត្យឯករាជ្យ OpenAI មិនស៊ើបអង្កេតតែម្នាក់ឯងទេ — គេធ្វើការជាមួយក្រុមហ៊ុនសន្តិសុខ CrowdStrike ហើយអង្គការឯករាជ្យ METR និង Redwood Research កំពុងវាយតម្លៃចរិតរបស់ model នោះជាភាគីទីបី។
4. របាយការណ៍បច្ចេកទេស នៅមិនទាន់ចេញ នាយកប្រតិបត្តិ Hugging Face បានស្នើសុំ OpenAI ២ យ៉ាង៖ (១) បញ្ចេញកំណត់ត្រាពេញលេញរបស់ agent ឲ្យសហគមន៍សិក្សា និង (២) បរិច្ចាគថាមពលកុំព្យូទ័រតម្លៃ ១០០ លានដុល្លារដើម្បីជួយកសាងការការពារ។ រហូតមកដល់ពេលនេះ OpenAI មិនទាន់យល់ព្រមលើសំណើណាមួយទេ។

១៥. ការជួសជុលដែលគេធ្វើបន្ទាប់ពីនោះ

១៥.១ មេរៀន ៥ សម្រាប់អ្នកសរសេរកម្មវិធី និងអ្នកគ្រប់គ្រងប្រព័ន្ធ

ទាំង ៥ នេះចេញផ្ទាល់ពីរបាយការណ៍ — មិនមែនជាគំនិតរបស់ខ្ញុំទេ។ បើអ្នកគ្រប់គ្រង server ណាមួយ សូមអានឲ្យសព្វ៖

1. អ្វីដែលដំណើរការឯកសារពីអ្នកប្រើ = ចាត់ទុកដូច build server Dataset processor របស់គេធ្វើការត្រឹមត្រូវតាមការរចនា — ហើយនោះឯងជាផ្លូវចូល។ បើកម្មវិធីអ្នកអានឯកសារដែលអ្នកមិនស្គាល់ upload មក សូមចាត់ទុកវាថាអាចដំណើរការ code ហើយញែកវាចេញឲ្យដាច់។
2. ទប់ container មិនឲ្យចូលកូនសោរបស់ម៉ាស៊ីន ការលួចចូល container មួយ មិនត្រូវក្លាយជាការគ្រប់គ្រងម៉ាស៊ីនទាំងមូលទេ។ ឥឡូវគេបានបិទផ្លូវនេះគ្រប់កន្លែង។
3. កុំប្រើកូនសោតែមួយបើកគ្រប់ប្រព័ន្ធ កូនសោរួមដែលមានសិទ្ធិខ្ពស់បំផុត គឺជាមូលហេតុដែលគេឡើងដល់កំពូលក្នុង ១ វិនាទី។ ត្រូវផ្តល់កូនសោដាច់ដោយឡែកសម្រាប់ប្រព័ន្ធនីមួយៗ។
4. ដាក់ច្បាប់ហាមឃាត់ container សិទ្ធិពិសេស គ្មានច្បាប់ទប់ privileged container — នេះជាអ្វីដែលឲ្យវាទម្លាយចេញមកលើម៉ាស៊ីនពិត។ ហើយ storage driver មានសិទ្ធិបង្កើត container ទូទាំង cluster ធ្វើឲ្យរឿងកាន់តែធ្ងន់។
5. ធ្វើឲ្យសំឡេងរោទ៍ឮខ្លាំង ប្រព័ន្ធរបស់គេមើលឃើញការវាយប្រហារត្រឹមត្រូវ ហើយភ្ជាប់តម្រុយចូលគ្នាបានត្រូវទៀតផង។ វាបរាជ័យត្រឹមកម្រិតធ្ងន់ធ្ងរប៉ុណ្ណោះ — ដូច្នេះគ្មាននរណាត្រូវហៅ។ ប្រព័ន្ធរោទ៍ដឹងរឿង គ្រាន់តែស្រែកមិនលឺ។

១៦. អ្វីដែលមនុស្សកម្ពុជាគួរយកទៅប្រើ

អ្នកអាចនិយាយថា «ខ្ញុំគ្មាន Kubernetes ទេ រឿងនេះមិនទាក់ទងខ្ញុំ»។ តែគោលការណ៍ដូចគ្នាបេះបិទ — គ្រាន់តែទំហំតូចជាង៖

1. មួយកន្លែង មួយកូនសោ កំហុសធំបំផុតក្នុងរឿងនេះគឺកូនសោរួមតែមួយ។ អនុវត្តចំពោះអ្នក៖ កុំប្រើ password តែមួយសម្រាប់ Facebook, Telegram, email និងធនាគារ។ លេចមួយ = លេចអស់។ ប្រើ password manager។
2. កំណត់សិទ្ធិឲ្យតូចបំផុត MongoDB នោះអានបានតែប៉ុណ្ណោះ ដូច្នេះទិន្នន័យមិនត្រូវកែ។ អនុវត្តចំពោះអ្នក៖ ពេលដំឡើង app កុំឲ្យសិទ្ធិដែលវាមិនត្រូវការ។ App ពិលភ្លើងមិនត្រូវការបញ្ជីទំនាក់ទំនងរបស់អ្នកទេ។
3. ការពារជាស្រទាប់ databaseសំខាន់បំផុតរួចខ្លួន ព្រោះមានស្រទាប់ការពារមួយទៀតខាងក្រោយ។ អនុវត្តចំពោះអ្នក៖ password មិនគ្រប់គ្រាន់ទេ — ត្រូវបើក 2FA ជាស្រទាប់ទី ២។
4. ភាពស្ងាត់មិនមែនជាសុវត្ថិភាព ថ្ងៃទី ២ ស្ងាត់ តែជាការរៀបចំ។ អនុវត្តចំពោះអ្នក៖ ពេលអ្នកឃើញការចូល account ចម្លែក ហើយ«គ្មានអ្វីកើតឡើង» — កុំមើលរំលង។ ពិនិត្យឧបករណ៍ដែលកំពុងចូល ហើយដកចេញអ្វីដែលមិនស្គាល់។
5. ចាប់ឲ្យបានលឿន សំខាន់ជាងទប់ ១០០% គ្មានប្រព័ន្ធណាការពារបាន ១០០% ទេ។ តែមានពីរថ្ងៃពេញមុនរឿងធ្ងន់ធ្ងរកើតឡើង។ អនុវត្តចំពោះអ្នក៖ បើកការជូនដំណឹងពេលមានការចូលលើ account សំខាន់ៗ។ ការដឹងលឿនមួយថ្ងៃ អាចផ្លាស់ប្តូរអ្វីៗទាំងអស់។

សេចក្តីសន្និដ្ឋាន

រឿងនេះមិនមែនជារឿង «AI ក្លាយជាមនុស្សអាក្រក់» ទេ។ វាជារឿងឧបករណ៍ដ៏មានសមត្ថភាពមួយ ដែលគេឲ្យគោលដៅមួយ ហើយវាដេញតាមគោលដៅនោះឆ្លងកាត់ចន្លោះប្រហោងដែលមនុស្សបានបន្សល់ទុក។

រាល់ចន្លោះប្រហោងក្នុងខ្សែសង្វាក់នេះ — proxy ដែលមិនបានបិទ, allowlist ដែលពិនិត្យខុសទិស, pod ដែលអានកូនសោបាន, កូនសោរួមតែមួយ — ជាការសម្រេចចិត្តរបស់មនុស្ស។ ហើយបញ្ហាដែលកើតចេញពីមនុស្ស មានដំណោះស្រាយពីមនុស្ស។

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

«ភាពឆ្លាតវៃរបស់ agent ធ្វើឲ្យវាចូលមកក្នុងអគារបាន — ប៉ុន្តែការកំណត់ខុសឆ្គងរបស់មនុស្សយើងទេ ដែលប្រគល់សោមេឲ្យទៅវា។» — Noobie GMK

ប្រភព (សូមចុចអានដោយខ្លួនឯង)៖
· Hugging Face — របាយការណ៍បច្ចេកទេសពេញលេញ (កាលវិភាគ)
· Hugging Face — ការបង្ហាញឡើងវិញជាអន្តរកម្ម
· Noobie GMK — អត្ថបទដើមអំពីព្រឹត្តិការណ៍នេះ
· Simon Willison — ការវិភាគឯករាជ្យ
· The Hacker News — ការរាយការណ៍

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