RBAC 基于角色的權限訪問控制

在20世紀90年代期間锌半,大量專家學者和研究單位對RBAC(Role-Based Access Control)的概念進行了深入研究,先后提出了許多類型的RBAC模型戴涝,其中以美國George Mason大學信息安全技術實驗室(LIST)提出的RBAC96模型最具系統(tǒng)性究抓,并得到普遍的公認屋灌。

傳統(tǒng)的權限分配的方式是將用戶與權限綁定邪财,也就是直接將權限綁定到用戶身上陕壹,例如之前盛行的ACL模型。這種做法的缺陷在于效率低下树埠,設置權限時沒有統(tǒng)一的標準糠馆。當用戶量過多時,操作復雜麻煩怎憋。

在RBAC中需要對系統(tǒng)的所有資源進行權限控制又碌,系統(tǒng)資源可以簡單地概括為靜態(tài)資源(功能操作、數(shù)據(jù)列)和動態(tài)資源(數(shù)據(jù))绊袋,也分別稱為對象資源和數(shù)據(jù)資源毕匀。RBAC的目標是對系統(tǒng)中所有對象資源和數(shù)據(jù)資源進行權限控制。

RBAC是什么

RBAC基于角色的訪問控制是用戶通過角色與權限進行關聯(lián)癌别,為什么不直接給用戶分配權限呢皂岔?簡單來說,一個用戶擁有多個角色规个,每個角色擁有若干權限凤薛。這樣就構成了“用戶-角色-權限”的授權模型姓建。在這個模型中诞仓,用戶與角色缤苫、角色與權限之間是多對多的關系。

RBAC

角色是什么呢墅拭?

角色可以理解為一定數(shù)量的權限的集合活玲,也就是權限的載體。當用戶數(shù)量越來越大的時候谍婉,就需要為用戶分組舒憾,每個用戶組內擁有不同的用戶,除了可以給用戶授權外穗熬,也可以給用戶組授權镀迂。如此一來,用戶擁有的所有權限就是用戶個人擁有的權限與該用戶所在用戶組擁有的權限之和唤蔗。

用戶組

用戶組與角色有何區(qū)別呢探遵?

用戶組是用戶的集合,但不是權限的集合妓柜。角色同時具有用戶集合和權限集合的概念箱季,角色是把兩個集合聯(lián)系在一起的中間媒介。如果用戶組的權限和成員僅能被系統(tǒng)安全員修改的話棍掐,用戶組的機制是非常接近于角色的概念的藏雏。角色也可以在用戶組的基礎上實現(xiàn),這有利于保持原有系統(tǒng)中的控制關系作煌。在這種情況下掘殴,角色相當于一個策略部件,與用戶組的授權及責任關系相聯(lián)系粟誓,而用戶組則是實現(xiàn)角色的機制杯巨。因此,兩者之間是策略與實現(xiàn)機制之間的關系努酸。

權限是什么呢服爷?

權限表現(xiàn)在對功能模塊的操作,例如對上傳文件的刪除和修改获诈,對菜單的訪問仍源,甚至是對頁面上某個按鈕或圖片可見性的控制,都是屬于權限的范疇舔涎。在做數(shù)據(jù)表建模時可將功能操作和資源進行統(tǒng)一管理笼踩,直接與權限表進行關聯(lián),這樣更具便捷性和易擴展性亡嫌。

可見權限分為

  • 頁面權限
    Web系統(tǒng)由一個一個頁面組成嚎于,頁面構成了模塊掘而,用戶能夠看到這個頁面的菜單,是能進入某個頁面就成為頁面權限于购。
  • 操作權限
    用戶在系統(tǒng)中交互動作都是操作權限袍睡,典型的例如增刪改查操作。
  • 數(shù)據(jù)權限
    業(yè)務管理系統(tǒng)中對數(shù)據(jù)私密性有要求時肋僧,哪些人可以看到哪些數(shù)據(jù)斑胜,看不到哪些數(shù)據(jù)。
權限分類

RBAC權限模型的擴展模型的完整設計

RBAC完整設計

RBAC本質

RBAC的本質是單純地用戶和權限進行解耦嫌吠,將用戶與角色止潘、角色與權限關聯(lián)。

用戶角色權限

RBAC認為權限的過程可以抽象為:判斷誰(Who)是否可以對什么(What)進行怎樣(How)的訪問操作(Operator)辫诅,簡單來說凭戴,就是對這個邏輯表達式的值是否為真(True)的求解過程。進而將權限問題轉換為Who炕矮、What么夫、How的問題,因此Who吧享、What魏割、How構成了訪問權限的三元組。

  • Who 權限的擁有者或主體钢颂,如User钞它、Role、Group殊鞭、Actor遭垛、Principal...
  • What 權限針對的對象或資源,如Operator操灿、Object锯仪、Class、Resource...
  • How 具體的權限趾盐,主要是Privilege庶喜,可進行正向授權和反向授權。

RBAC相關概念

  • User 用戶

用戶對應著系統(tǒng)中的具體操作者救鲤,用戶可以自己擁有權限久窟,也可以歸屬于零個或多個角色,也可以屬于零個或多個組本缠,用戶的權限集是自身所具有的權限斥扛、所屬角色具有的權限,所屬組具有的權限的合集丹锹,用戶與權限稀颁、角色芬失、組之間的關系都是多對多的關系。

  • Operator 操作

Operator 表明對What的How操作匾灶,也就是Privilege+Resource的組合棱烂。

  • Privilege 權限

權限由操作與資源組成,表示對資源的一個操作粘昨。角色與權限的關系是多對多的垢啼,這一點是權限的核心窜锯。

  • Role 角色

Role 表示一定數(shù)量權限的集合张肾,權限分配的單位與載體,目的是隔離用戶和權限的邏輯關系锚扎。角色是為許多擁有相似權限的用戶進行的分類管理吞瞪,角色具有上下級關系,可形成樹狀結構驾孔,父級角色的權限是自身以及子角色權限的總和芍秆。角色作為用于與權限的代理層,解耦了權限與用戶的關系翠勉,所有的授權應該給與角色而不是直接分配給用戶或組妖啥。

  • Group 用戶組

Group 是權限分配的單位與載體,權限不考慮分配給特定的用戶而給組对碌,組可以包含組以實現(xiàn)權限的繼承荆虱,也可以包含用戶,組內用戶繼承組的權限朽们。用戶與組的關系是多對多的怀读,組可以層次化以滿足不同級別權限控制的要求泥技。
為了更好地管理用戶秒旋,對用戶進行分組歸類。組也具有上下級關系涮较,可形成樹狀結構叁丧。

  • Session會話

Session在RBAC中是一個比較隱晦的元素啤誊,準確來說,每個Session都是一個映射拥娄,一個用戶到多個Role角色的映射蚊锹。當一個用戶激活它所有角色的一個子集時會建立一個Session會話。每個Session會話和單個User用戶可以關聯(lián)到一個或多個Session會話条舔。

RBAC的關注點在于角色枫耳、用戶、權限三者之間的關系即用戶授權(User Assignment, UA)和權限分配(Permission Assignment孟抗,PA)迁杨,關系的左右都是多對多的關系钻心,用戶可以有多個角色,角色可以包括多個用戶铅协。簡單來說捷沸,用戶授權和權限分配相當于中間表狐史,事實上整個RBAC都是基于關系的模型。

RBAC中用戶實際上是在扮演角色骏全,可以使用Actor取代User,考慮到多人可以擁有相同的權限姜贡,RBAC引入了Group組的概念试吁,Group組同樣也可以看作是Actor楼咳,而User的概念就是具體到一個人。

RBAC分析模型

RBAC作為一種分析模型母怜,主要分為四部分RBAC0~RBAC3余耽,RBAC96模型家族中包含了這四個概念模型。

NIST(The National Institute of Standards and Technology苹熏,美國國家標準與技術研究院)標準RBAC模型由四個部件模型組成,這四個部件模型分別是:

RBAC

RBAC0(Core RBAC)基礎模型

RBAC0是RBAC的核心柜裸,RBAC1、RBAC2扛邑、RBAC3都是先后在RBAC0的基礎上進行擴展铐然。

RBAC0定義了能夠構成RBAC控制系統(tǒng)的最小的元素集合,換句話說搀暑,RBAC0定義了完全支持RBAC概念的任何系統(tǒng)的最低需求。

RBAC0由四部分構成:User用戶桐罕、Role角色、Session會話溅潜、Permission權限

RBAC0

權限包含“操作”和“控制對象”薪伏,權限應該賦予角色而非用戶。當一個用戶被指派給一個角色時设捐,此用戶就擁有了該角色所包含的權限塘淑。另外會話是一個動態(tài)的概念,用戶必須通過會話才可以設置角色朴爬,此時用戶與激活的角色之間的映射關系橡淆。

RBAC1(Hierarchal RBAC)角色分層模型

RBAC1引入了角色間的繼承關系,也就是說具滴,角色上有了上下級的區(qū)別师倔。

RBAC1

角色間的繼承關系可分為一般繼承關系和受限繼承關系

  • 一般繼承關系僅僅要求角色繼承關系是一個絕對偏序關系,允許角色之間的多繼承疲恢。
  • 受限繼承關系則進一步要求角色繼承關系是一個樹狀結構瓷胧,實現(xiàn)角色間的單繼承。

RBAC1適用于角色之間的層次明確搓萧,包含關系清晰的場景。

RBAC2(Constraint RBAC)角色限制模型

RBAC2是基于RBAC0的模型揍移,并增加了對角色的限制:角色互斥反肋、基數(shù)約束那伐、先決條件角色...

RBAC2添加了責任分離關系,RBAC2的約束規(guī)定了權限被賦予角色時读规,或角色被賦予用戶時燃少,以及當用戶在某一時刻激活一個角色時應當遵循的強制性規(guī)則。

責任分離包括靜態(tài)責任分離和動態(tài)責任分離碍遍,約束與“用戶-角色-權限”關系一起決定了RBAC2中用戶的訪問許可阳液。

RBAC2的約束分為

  • 角色互斥

同一用戶只能分配到一組互斥角色集合中最多一個角色,支持責任分離原則帘皿∮チ铮互斥角色是指各自權限相互制約的兩個角色,對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色曹动,不能同時獲得兩個角色的使用權。例如恶守,在審計活動中一個角色不能同時被指派為會計角色和審計員角色贡必。

  • 基數(shù)約束

一個角色被分配的用戶數(shù)量受限,一個用戶可擁有的角色數(shù)目受限衫樊,同樣一個角色對應的訪問權限數(shù)量也應當受限兑徘,以控制高級權限在系統(tǒng)中的分配羡洛。

  • 先決條件角色

可以分配角色給用戶僅當該用戶已經(jīng)是另一個角色的成員肋联,對應的可以分配訪問權限給角色牍戚,僅當該角色已經(jīng)擁有另一種訪問權限。要想獲得較高的權限,需要首先擁有第一級別的權限。

  • 運行時互斥

運行中不能同時激活多個角色

RBAC3(Combines RBAC)統(tǒng)一模型

RBAC3是最全面的權限管理,它是基于RBAC0基礎上赘方,將RBAC1和RBAC2整合后的統(tǒng)一模型跳夭。

RBAC3稱為統(tǒng)一模型,包含了RBAC1和RBAC2,利用傳遞性也就將RBAC0包含在內锚赤。

RBAC3

RBAC安全原則

RBAC支持公認的安全原則:

  • 最小特權的安全原則

在RBAC模型中可通過限制分配給角色權限的多少和大小來實現(xiàn)锭吨,分配給與某用戶對應的角色的權限只要不超過該用戶完成其任務的需要就可以了锄弱。

  • 責任分離原則

在RBAC模型中可通過在完成敏感任務過程中分配兩個任務上相互約束的兩個角色來實現(xiàn)掸鹅,例如在清查賬目時句携,只需要設置財務管理員和會計兩個角色參加就可以了蠢笋。

  • 數(shù)據(jù)抽象原則

數(shù)據(jù)抽象是借助于抽象許可權的概念實現(xiàn)的炊邦,例如在賬目管理活動中,可使用信用、借方等抽象許可權,而不是使用操作系統(tǒng)提供的讀、寫反番、可執(zhí)行等具體的許可權叉钥。RBAC中并強迫實現(xiàn)這些原則,安全管理員可以允許配置RBAC模型使其不支持這些原則。因此雁芙,RBAC支持數(shù)據(jù)抽象的程度與實現(xiàn)細節(jié)有關谎碍。

RBAC優(yōu)缺點

  • 基于角色與權限之間的變化要比角色與用戶之間的變化相對少得多,也就減少了授權管理的復雜性惦费,降低了管理的開銷瞧省。
  • 靈活地支持企業(yè)的安全策略,并對企業(yè)的變化由很大的伸縮性臀突。
  • RBAC沒有提供操作順序控制機制梳码,這一缺陷使得RBAC模型很難應用于要求有嚴格操作次序的實體系統(tǒng)。

數(shù)據(jù)表設計

用戶賬號表

應用系統(tǒng)過的具體操作者掰茶,用戶可以擁有權限信息,也可以歸屬于0~n個組盐碱。用戶的權限集是自身具有的權限沪伙、所屬組具有的權限、所屬角色具有的權限的合集暖混。用戶與群組翁授、角色晾咪、權限之間是多對多的關系贮配。

CREATE TABLE `web_account` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  `aid` int(11) unsigned DEFAULT '0' COMMENT '賬戶ID 唯一編號',
  `account` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '賬號',
  `password` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '密碼',
  `salt` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '密碼加鹽',
  `creator` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '創(chuàng)建人',
  `create_time` int(10) unsigned DEFAULT '0' COMMENT '創(chuàng)建時間',
  `create_date` datetime DEFAULT NULL COMMENT '創(chuàng)建日期',
  `updator` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '更新人',
  `update_time` int(10) unsigned DEFAULT '0' COMMENT '修改時間',
  `update_date` datetime DEFAULT NULL COMMENT '修改日期',
  `login_time` int(10) unsigned DEFAULT '0' COMMENT '最近登錄時間',
  `login_date` datetime DEFAULT NULL COMMENT '最近登錄日期',
  `login_ip` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '最近登錄IP',
  `login_error` tinyint(4) unsigned DEFAULT '0' COMMENT '錯誤登錄次數(shù)',
  `logout_time` int(10) unsigned DEFAULT '0' COMMENT '下線時間',
  `logout_date` datetime DEFAULT NULL COMMENT '下線日期',
  `token` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '登錄令牌',
  `lock` tinyint(1) DEFAULT '0' COMMENT '鎖定狀態(tài) 0禁用 1啟用',
  `lock_time` int(10) DEFAULT '0' COMMENT '鎖定時間',
  `lock_date` datetime DEFAULT NULL COMMENT '鎖定日期',
  `online` tinyint(1) unsigned DEFAULT '0' COMMENT '在線狀態(tài) 0下線 1在線',
  `remark` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '備注說明',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='賬號';

群組表

為了更好的管理用戶剂跟,對用戶進行分組歸類酣藻,簡稱為用戶分組。群組是具有上下級關系辽剧,可形成樹狀層次結構的視圖怕轿。在實際業(yè)務中,群組是可以具有自己的角色信息和權限信息的撞羽。對比QQ群會發(fā)現(xiàn),一個群可以有多個用戶谒出,一個用戶也可以加入多個群邻奠。每個群都具有自己的權限信息,例如查看群共享等杀狡。另外贰镣,群也具有自己的角色信息。

群組關系

用戶董朝、群組干跛、角色祟绊、權限這四者之間的關系由于自身都會存在上下層次的,相對而言有些繁瑣嘉熊。

CREATE TABLE `web_group` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增編號',
  `gid` int(11) unsigned DEFAULT '0' COMMENT '群組ID 唯一',
  `pid` int(11) unsigned DEFAULT '0' COMMENT '上級編號',
  `level` int(11) unsigned DEFAULT '0' COMMENT '群組層級',
  `path` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '層級路徑',
  `type` tinyint(1) unsigned DEFAULT '1' COMMENT '群組類型',
  `name` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '群組名稱',
  `notice` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '群組公告',
  `remark` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '群組備注',
  `owner_id` int(11) unsigned DEFAULT '0' COMMENT '擁有者ID',
  `member_count` int(11) unsigned DEFAULT '0' COMMENT '成員數(shù)量',
  `children_count` int(11) unsigned DEFAULT '0' COMMENT '子群數(shù)量',
  `status` tinyint(3) unsigned DEFAULT '1' COMMENT '群組狀態(tài) 0禁用 1啟動',
  `create_time` int(10) unsigned DEFAULT '0' COMMENT '創(chuàng)建時間',
  `create_date` datetime DEFAULT NULL COMMENT '創(chuàng)建日期',
  `update_time` int(10) unsigned DEFAULT '0' COMMENT '更新時間',
  `update_date` datetime DEFAULT NULL COMMENT '更新日期',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='群組';

群組成員表

CREATE TABLE `web_group_member` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  `gid` int(11) unsigned DEFAULT '0' COMMENT '群組編號',
  `pid` int(11) unsigned DEFAULT '0' COMMENT '成員父級ID',
  `gmid` int(11) unsigned DEFAULT '0' COMMENT '成員ID',
  `role` tinyint(3) unsigned DEFAULT '0' COMMENT '成員角色',
  `status` tinyint(3) unsigned DEFAULT '1' COMMENT '成員狀態(tài) 0禁用 1啟用 2踢出',
  `remark` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '備注',
  `create_time` int(10) unsigned DEFAULT '0' COMMENT '創(chuàng)建時間',
  `create_date` datetime DEFAULT NULL COMMENT '創(chuàng)建日期',
  `update_time` int(10) DEFAULT '0' COMMENT '更新時間',
  `update_date` datetime DEFAULT NULL COMMENT '更新日期',
  `entry_time` int(10) unsigned DEFAULT '0' COMMENT '進入時間',
  `entry_date` datetime DEFAULT NULL COMMENT '進入日期',
  `exit_time` int(10) unsigned DEFAULT '0' COMMENT '踢出時間',
  `exit_date` datetime DEFAULT NULL COMMENT '踢出日期',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='群組成員';

角色表

為了對擁有相似權限的用戶或群組進行分類管理凫佛,定義了角色的概念孕惜。角色具有上下層次關系,可形成樹狀層次結構的視圖衫画。父級角色的權限是自身及其子角色權限的綜合削罩。

CREATE TABLE `web_role` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增編號',
  `rid` int(11) unsigned DEFAULT '0' COMMENT '唯一編號',
  `pid` int(11) unsigned DEFAULT '0' COMMENT '父級編號',
  `level` int(11) unsigned DEFAULT '0' COMMENT '所屬層級',
  `path` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '層級路徑',
  `type` tinyint(1) unsigned DEFAULT '1' COMMENT '角色類型',
  `name` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '角色名稱',
  `status` tinyint(3) unsigned DEFAULT '1' COMMENT '角色狀態(tài)',
  `remark` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '備注說明',
  `create_time` int(10) unsigned DEFAULT '0' COMMENT '創(chuàng)建時間',
  `create_date` datetime DEFAULT NULL COMMENT '創(chuàng)建日期',
  `update_time` int(10) unsigned DEFAULT '0' COMMENT '更新時間',
  `update_date` datetime DEFAULT NULL COMMENT '更新日期',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='角色';

權限節(jié)點表

CREATE TABLE `web_node` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  `nid` int(11) unsigned DEFAULT '0' COMMENT '唯一編號',
  `name` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '節(jié)點名稱',
  `module` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '模塊標識',
  `controller` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '控制器標識',
  `action` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '方法標識',
  `url` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '節(jié)點地址',
  `pid` int(11) unsigned DEFAULT '0' COMMENT '父級編號',
  `level` tinyint(3) unsigned DEFAULT '0' COMMENT '節(jié)點層級',
  `path` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '節(jié)點路徑',
  `type` tinyint(3) unsigned DEFAULT '0' COMMENT '節(jié)點類型',
  `status` tinyint(3) unsigned DEFAULT '1' COMMENT '節(jié)點狀態(tài)',
  `remark` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '備注說明',
  `create_date` datetime DEFAULT NULL COMMENT '創(chuàng)建日期',
  `create_time` int(10) unsigned DEFAULT '0' COMMENT '創(chuàng)建時間',
  `update_date` datetime DEFAULT NULL COMMENT '更新日期',
  `update_time` int(10) unsigned DEFAULT '0' COMMENT '更新時間',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='權限節(jié)點';

未完待續(xù)...

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末进陡,一起剝皮案震驚了整個濱河市微服,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌职辨,老刑警劉巖,帶你破解...
    沈念sama閱讀 216,591評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件喳资,死亡現(xiàn)場離奇詭異腾供,居然都是意外死亡伴鳖,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,448評論 3 392
  • 文/潘曉璐 我一進店門搞疗,熙熙樓的掌柜王于貴愁眉苦臉地迎上來须肆,“玉大人桩皿,你說我怎么就攤上這事幢炸。” “怎么了宛徊?”我有些...
    開封第一講書人閱讀 162,823評論 0 353
  • 文/不壞的土叔 我叫張陵闸天,是天一觀的道長。 經(jīng)常有香客問我缰揪,道長葱淳,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,204評論 1 292
  • 正文 為了忘掉前任艳狐,我火速辦了婚禮皿桑,結果婚禮上,老公的妹妹穿的比我還像新娘诲侮。我一直安慰自己,他們只是感情好刮便,可當我...
    茶點故事閱讀 67,228評論 6 388
  • 文/花漫 我一把揭開白布绽慈。 她就那樣靜靜地躺著坝疼,像睡著了一般。 火紅的嫁衣襯著肌膚如雪钝凶。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,190評論 1 299
  • 那天桌硫,我揣著相機與錄音,去河邊找鬼。 笑死南用,一個胖子當著我的面吹牛,可吹牛的內容都是我干的肿嘲。 我是一名探鬼主播筑公,決...
    沈念sama閱讀 40,078評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼封救!你這毒婦竟也來了捣作?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 38,923評論 0 274
  • 序言:老撾萬榮一對情侶失蹤惩坑,失蹤者是張志新(化名)和其女友劉穎也拜,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體蔓钟,經(jīng)...
    沈念sama閱讀 45,334評論 1 310
  • 正文 獨居荒郊野嶺守林人離奇死亡岸军,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,550評論 2 333
  • 正文 我和宋清朗相戀三年艰赞,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片方妖。...
    茶點故事閱讀 39,727評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖雌澄,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情炫掐,我是刑警寧澤睬涧,帶...
    沈念sama閱讀 35,428評論 5 343
  • 正文 年R本政府宣布,位于F島的核電站痹束,受9級特大地震影響讶请,放射性物質發(fā)生泄漏。R本人自食惡果不足惜夺溢,卻給世界環(huán)境...
    茶點故事閱讀 41,022評論 3 326
  • 文/蒙蒙 一企垦、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧钞诡,春花似錦、人聲如沸接箫。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,672評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽废累。三九已至脱盲,卻和暖如春邑滨,著一層夾襖步出監(jiān)牢的瞬間钱反,已是汗流浹背匣距。 一陣腳步聲響...
    開封第一講書人閱讀 32,826評論 1 269
  • 我被黑心中介騙來泰國打工毅待, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留归榕,地道東北人。 一個月前我還...
    沈念sama閱讀 47,734評論 2 368
  • 正文 我出身青樓驶乾,卻偏偏與公主長得像循签,于是被迫代替她去往敵國和親疙咸。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 44,619評論 2 354