<code id="hhktd"></code>
    <ins id="hhktd"><option id="hhktd"></option></ins>
  • <ins id="hhktd"><video id="hhktd"><var id="hhktd"></var></video></ins>

        <tr id="hhktd"><track id="hhktd"></track></tr>
        <menuitem id="hhktd"><acronym id="hhktd"></acronym></menuitem>

        1. <ins id="hhktd"><video id="hhktd"></video></ins>
        2. 侵權投訴
          訂閱
          糾錯
          加入自媒體

          “退微信群”謠言背后:總是有人用陰謀論湮沒常識

          2021-11-29 09:39
          腦極體
          關注

          近日,有個傳聞稱騰訊云數據庫泄露,部分企業開始退微信群。在網傳聊天圖片中,有網友稱“網信辦拉了個騰訊云大客戶列表,正在挨個打電話核查”,也有網友表示:“傳鵝廠數據庫已泄露,部分國企事業單位已經開始退微信群!

          對此,騰訊在其“鵝廠黑板報”微信公眾號發文回應稱,該傳聞是謠言,并請大家不信謠不傳謠。

          “退微信群”謠言背后:總有人用陰謀論湮沒常識

          在網絡世界里面快樂馳騁的時候,最煩人的就是真真假假的信息和滿天飛的謠言。尤其是謠言的傳播速度和傳播內容,帶給人非常負面的影響和體驗。

          拿最近上熱搜的謠言新聞來說,孫女和外公的寫真合影被一些不三不四的嘴巴添油加醋地包裝成富豪包養年輕姑娘的故事,給當事人造成了非常大的傷害,好在這些造謠的臭嘴都被拘留了。

          喜歡捕風捉影,造謠生事的嘴巴確實都應該好好管管了?吹津v訊云數據庫泄露的造謠新聞,也讓人忍不住想要理一理謠言里的漏洞分析一番:為什么都到2021年了,依舊有人對APP、云這些基礎設施的安全常識一無所知?

          泄密的源頭應該指向哪里?

          單看網傳的騰訊云數據庫泄露說法,根本就是無稽之談。拿信息截圖的傳播分享的過程中遭遇信息泄露說是騰訊云數據庫泄露,對于這個結論的得出過程很迷,無法理解造謠人士是如何得出的這個結論,也不知道引的是哪里的消息人士。我們知道社交平臺的價值起初是作為人們日常生活的人際互動、擴展信息交友的基礎工具,隨著微信、釘釘等平臺的便捷性,有很多除社交以外的工作協同等信息內容也在這類社交平臺里傳播。

          社交平臺帶來便捷性的同時,也會在內容傳播的過程中有一定的風險泄露信息。但深究一下,信息泄露的風險到底是平臺的原因呢?還是我們在使用的過程中保密的意識不夠呢?

          對于工作中的涉密信息等,我們在傳播的過程中有沒有摻雜些防人的心思呢?與對接涉密信息無關的人員,我們在分享群信息的時候有沒有考慮過涉密信息被泄露的可能,簡單的一句“不要外傳”,真的會不外傳嗎?在社交平臺中,對于涉密的信息還是從源頭的傳播上保持警惕。

          在日常的社交應用平臺中,我們都見過這類人,動不動就截圖,不看圖中是否截到了其他信息、其他人,也沒有保護他人隱私信息的意識,更別說打碼的基礎操作。我們在大群的聊天中,也會看到有人將一些與他人聊天的記錄、照片等內容打包分享到大群,供他人品析,行為非常惡臭。這種在大群里披著人皮的隱身人,喜歡分享隱私、無事生非,讓人防不勝防。

          “退微信群”謠言背后:總有人用陰謀論湮沒常識

          最新鮮的記憶就是在疫情防控期間,有些人隨意編造有關疫情的聊天截圖在微信群或者朋友圈瘋狂傳播,這也是不少謠言的源頭,不僅惑亂人心,也給防疫造成很大的負面影響。今年7月下旬的一輪疫情中,根據人民網輿情數據中心的統計樣本,網上的大量謠言中,聊天截圖是涉疫謠言的主要源頭之一。

          在當下社會,社交媒體作為一種基礎性的信息工具已深入滲透到人們的日常生活中。我們在通過社交媒體獲取信息、擴展人際關系時,對于隱私和涉密的信息還是需要保密的意識;厮轃o數泄密的所謂大瓜事件,很多都是通過社交平臺的信息截圖轉發導致的,這種類型的泄密重要的是使用者自身的保密意識。而企業內部的溝通協作中也不乏截圖滿天飛的情形,這種信息的泄密跟用什么應用或者平臺無關。無法篩查出泄密的小人情況下,用什么平臺、應用都一樣,都得需要自身加強信息保密意識,才能防范信息的泄露。使用者不在意信息安全的話,使用什么平臺都有信息安全泄露的風險。

          數據庫泄密的可能性

          如果從數據泄露的途徑來分析的話,數據泄露的主要方式有三種包括:竊密、泄密、失密。而我們今天討論的范圍是有關騰訊云是否有泄露數據庫嫌疑,即云企業是否會有泄密的可能性。

          我們知道從PC互聯網進入移動互聯網時代,通過移動設備使用云應用程序已經成為主流趨勢,這也就使得應用程序層的安全至關重要。云廠商會采取針對數據進行硬性隔離與數據優化控制的方式,保障應用中數據的安全性。

          對于云上數據庫來說存在泄密可能性的只有一種情形,就是內部員工通過訪問權限管理的熟悉,因為某些利益原因泄密。

          “退微信群”謠言背后:總有人用陰謀論湮沒常識

          從近兩年發生的信息泄漏事件中,我們看到“內部員工”逐漸成為了數據安全防護機制中最突出的“安全漏洞”。例如在去年四月,浙江某銀行有內部人員違規泄露客戶信息。其中,浙江某農商銀行被銀保監會罰款30萬,泄露信息的內部員工被禁業三年。2020年8月,不法分子與圓通快遞多位“內鬼”勾結,通過有償租用圓通員工系統賬號盜取公民個人信息,導致40萬條公民個人信息被泄漏。案件在11月被曝光后引起軒然大波。類似泄露客戶個人信息案件的“內鬼”多來自運營商、銀行、物流等掌握大量個人信息的行業。在凈網專項行動中,公安機關在侵犯公民個人信息案件中抓獲各行業“內鬼”3000余名。

          有關騰訊云數據庫泄露的謠言中,并沒有任何內部員工泄露的說法,而云企業主動去泄密的這種情形更不可能存在,這種說法和謠言是空穴來風,似乎沒啥站得住腳的理由。

          當然對員工泄密的方式進行規避只是云安全的部分,云廠商還會采取其他的方案來保障企業客戶以及應用、平臺等的安全,比如終端安全、應用安全、數據安全、云安全等業務。那么對于用戶來說,云是安全的嗎?

          云到底安全嗎?

          云安全是一個概念比較寬泛的話題,主要包含三個方向,云計算安全、安全基礎設施的云化、云安全服務。我們要討論的云安全是限制在云計算安全的范圍內,也就是有關用戶數據的安全存儲與隔離、信息傳輸安全、網絡攻擊防護等。而對于這種類型的云安全來說,面臨的威脅一般是數據破壞、數據丟失、不安全的接口和API,賬戶或者業務流量被劫持等情形。

          而謠言中的騰訊云數據庫泄露,騰訊下場親自辟謠,并沒有發生這些數據庫損壞、數據丟失等情形。主動泄露這種猜想更不可能出現,主動泄露信息的話對于與云廠商來說等同于自砸招牌與自掘墳墓。企業是靠賣云服務盈利的,多年的技術與渠道資源的積累,賣數據與賣服務之間的,企業比誰都清醒,一點點的蠅頭小利和長遠的價值之間,企業不會做出泄露數據庫與信息這種自殺式行為。主動泄露數據庫的這種說法以及行為在云廠商這邊是個不可能選項。

          “退微信群”謠言背后:總有人用陰謀論湮沒常識

          部分企業以安全為由選擇在微信中交流工作謹慎行事的說辭被夸大為數據庫泄露,群被解散等謠言,也就立不住腳。所以完全不涉及以安全為理由,限制員工使用微信的這種情形。

          在網絡平臺中,無論是個人隱私還是工作中的敏感信息,都需要我們使用者本身具有保密防護的意識,在傳播的源頭上去規避一些后續傳播過程泄密的可能性。而關于網絡上什么云廠商數據庫泄露、賣數據的這種說法,聽聽就算了,云廠商可能會有被黑客攻擊被販賣信息的可能性,但是說積累多年技術與資源的云廠商主動去賣信息純粹是在秀逗。在謠言滿天飛的情形下,不必聽風就是雨,陰謀論的因為一些小事過度引申造謠生事。畢竟,謠言不是沒有代價的。

          聲明: 本文由入駐維科號的作者撰寫,觀點僅代表作者本人,不代表OFweek立場。如有侵權或其他問題,請聯系舉報。

          發表評論

          0條評論,0人參與

          請輸入評論內容...

          請輸入評論/評論長度6~500個字

          您提交的評論過于頻繁,請輸入驗證碼繼續

          暫無評論

          暫無評論

          安防 獵頭職位 更多
          文章糾錯
          x
          *文字標題:
          *糾錯內容:
          聯系郵箱:
          *驗 證 碼:

          粵公網安備 44030502002758號

          无码人妻精品一区二区三区99
          <code id="hhktd"></code>
          <ins id="hhktd"><option id="hhktd"></option></ins>
        3. <ins id="hhktd"><video id="hhktd"><var id="hhktd"></var></video></ins>

              <tr id="hhktd"><track id="hhktd"></track></tr>
              <menuitem id="hhktd"><acronym id="hhktd"></acronym></menuitem>

              1. <ins id="hhktd"><video id="hhktd"></video></ins>