Q&A
「データベースに登録する情報の一部を、暗号化すべきとする記述」があったのはどのサイトですか? なにか根拠に基づくものなのか、たんなるヨタ話なのかわからないので。
経験が少ないため、みなさんの事例を聞ければと思い質問を立てました。
データベースに登録する情報に関しての質問です。
ネットを徘徊している際、データベースに登録する情報の一部を、暗号化すべきとする記述を見かけました。
個人的な感想として、データベースへの登録は素のデータを登録すべきで、暗号化すべきではないのではないかと思っています。
理由は
・可逆性があるのであれば、根本的に暗号化は無意味
・検索しにくくなる
といった点からです。
皆様の経験上、データベースへ登録する情報を暗号化するようなケースがあれば、教えていただけないでしょうか。
できれば、その暗号化の意図と詳細も教えていただけると幸いです。
よろしくお願いします。
一応質問のトリガーなので記述しましたが、本論とはあまり関係ないので、今回は記載しない方向で考えています。ご指摘ありがとうございます。
あまり気にせず経験や意見を回答すればいいわけですね。わかりました。
はい。よろしくお願いします＾＾できれば実例で！
確かに、明確に「ここが問題で解決したい点です」とは書いていないですね＾＾；
編集しようかとも思いましたが、実例をベースに回答を頂きたく、間口を狭めるのももったいないので、質問はこのまま行こうと思います。
ご指摘、ありがとうございました。
回答9件
0
ベストアンサー
情報セキュリティ要件を実装する上で、実践的規範としてPCI DSSというものがあります。
これはクレジットカード会社間からスタートした取り決めではありますが、
現在では情報セキュリティを導入する上でのグローバルスタンダードとなっています。
話が脱線してしまいましたが、
上記の要件によればクレジットカード情報等は明確に保護されなければならないとしています。
そのためクレジットカード番号はデータ暗号化が導入される一例となっています。
暗号化といってもデータ投入時の暗号化もあれば、DBMSが提供機能としてもデータ暗号化はあるので、
セキュリティ性の高い案件では機能も使われるということは知っておいて損はないと思われます。
セキュリティ一般に言えることですが、
常に攻撃者に突破される可能性を考慮した上で、
何重にも対策を張りめぐらせ、
一つ突破されても次で防御できるという状態を保つことが望ましいです。
コスト削減と利便性とはトレードオフの関係なので、
どこで妥協点を定めるかと言うのが一番難しい所ではあるのでしょうが^^;
###追記
コメントを受けまして少し追記をば。
データベース暗号化について、
DBMS(Oracle、SQL Serverなど)にもよるかもしれませんが、
データベース暗号化技術を利用しても基本的には現在のSQLをそのまま用いて暗号化・復号化の実施を行えるような機能を提供しております。テーブル暗号化
また顧客情報の内クレジットカード情報のみ暗号化したい等といった場合は、
カラム暗号化のように柔軟な仕組みを提供しているDBMSも存在します(Oracleなど)。
後、暗号化とは少し話が変わりますが、
ビューなどを利用して実テーブルの定義を隠ぺい(顧客の機密情報の入ったカラムを除いたビューを定義など）してセキュリティを確保するケースもありますね。
###さらに追記
暗号化と聞くと対外的な対策とイメージしやすいですが、
対内的にも牽制の意味で用いるとかはあるのかもですね。
(以下某試験問題の受け売り)
例えば普段はクレジットカード番号は暗号化し、
内部スタッフでも普段は参照は不可とする。
ある顧客(当然クレジットカード持ち主であることの本人確認はしっかり行うこと)から、
クレジットカード番号に関する問い合わせがあった場合、
オペレータはその顧客情報から検索した番号のみを復号して得る。
クレジットカード情報レベルとなると、
社内オペレータに対しても必要以上情報を開示してはいけないという考えによるものです。
###蛇足
IPAの主催している情報処理技術者試験の区分のひとつに、
「情報セキュリティスペシャリスト」(今年限りでこの名前の試験はなくなるのですが＾＾；)という試験があります。
確か２年ほど前の試験だったと思いますが、
ちょうど午後Ⅱの試験でPCI DSSとデータベースセキュリティをテーマとした問題が出題されました。
興味があればこの辺りの設問を読んでみるだけでも面白いかもしれません＾＾
投稿2016/08/09 11:10
編集2016/08/09 23:09
総合スコア1636
回答有り難うございます。
PCI DSS に準拠しようとすると、クレジットカード番号はデータベース内で暗号化されるという認識で正しいでしょうか？
その場合、どのように検索を行うのか、ご教示いただくことは可能ですか？
追記、非常に面白いです。
データベース暗号化に関して、Oracle 以外もできるものがあるのですね。知らなかったです。
暗号化カラムを検索キーにするケースの多い金融系では、DBMSで対応しているものを選択するのが一般的なんでしょうね。
ありがとうございました！
OracleさんなりのPCI DSS各要件と対応機能のまとめ表です(11g)
http://www.oracle.com/technetwork/jp/database/security/oracle-pci-089415-ja.html
こういうのも読んでみると面白いですね。
まぁ全部が全部ここまでガチガチにセキュリティを固めるというのはほんの一部を除き現実的ではないのですがね。
(PCI DSSは各要件で対応策が具体的に記載されてるから、参考にはされやすいけどこの要件を全て満たす必要のある案件なんてそうそうないかなと^^;)
業務から離れて要件対応表を見る機会ってあまりないので、こんなにも楽しいと知りませんでしたｗ
これ見ると、やはりOracleは優秀ですね。顧客からの要件を機能実装してきた歴史が感じられます。
MySQLの表面的機能しか使用したこと無いですが、まだこの領域には至っていないんでしょうね。
> 業務から離れて要件対応表を見る機会ってあまりないので、こんなにも楽しいと知りませんでしたｗ
全くもって同意見です。
この辺りの機能ってそれこそ特殊案件でないとお目にかかれないので、一生縁のない話にもなるかもですが…
こういう要件があって、こういう機能があるということを知るのも好奇心はくすぐられますよねw
まだ流石は天下のOracleで、
大金取るだけの実装は提供してるということでしょうね。
今の個人でやってる状況では、Oracleを使用する機会はなかなか無さそうです。
MySQLで同じような要件が出てきた時に、うまく実装する方法をご存知だったりしますか？
もしコメントいただけるようであれば、お願いします。
Oracle一択ですかね？
透過的暗号化はMySQLでもバージョン5.7よりサポートを開始してるようです。
→ https://www-jp.mysql.com/products/enterprise/tde.html
ただまだREDOログファイルでは暗号化されてないなど不完全な部分もあるようです(調べた感じですが)。
ただMySQLもOracleより買収されているので、
Oracleが本腰を入れると今後当該分野も強化されるかもしれませんね。
> 透過的暗号化はMySQLでもバージョン5.7よりサポートを開始してるようです。
これはありがたい。
てっきり無いものだと思って、質問してしまいました。
調べもせず、聞いてしまい申し訳ありません。
5.7の環境は無いので、しばらく試せませんが、どこかのタイミングで色々触ってみます！
ありがとうございました。
利用法的には他のDBMSと大差なさそうなので、
軽く触っておけばいざやるときにすんなり入れるかもですね。
後、前の質問への補足ですが、セキュリティ要件の高い案件だと恐らくユーザ側も多少コストがかかろうが信頼性(実績)を重視すると考えられるので、Oracle、SQL Serverなどの実績のあるプロダクトを採用するケースがほとんどかなと思います。
ちょっとしたパスワード暗号化対応とかだと、データベース暗号化よりはハッシュ(不可逆暗号方式)を利用することがほとんどですしね。
更に蛇足。
各種サイトでパスワードを忘れた際などにパスワード再発行リクエストを送った経験があると思いますが(僕は割とやらかします)、
この時本人確認のステップを踏んだ後に、一時的なログイン可能なパスワードを発行したり、速攻でパスワードを変更させるのパターンが多いと思います。
もちろんユーザが現時点で設定してあるパスワードを公衆に流すなんて論外という話もあるかと思いますが、
パスワードをハッシュ化して保存している場合は当然復元なんて不可能ですから、
ユーザに設定してもらうしか方法がないという理由もあるかもしれませんね。
いろいろ情報をありがとうございました。
非常にためになりました。
0
データベースに登録する値の一部をアプリケーションで暗号化する事に関してですね。
どのデータを暗号化すべきか（どこまで暗号化すべきか）というのはケースバイケースな部分もあるとは思いますが、パスワードや個人情報などが挙げられると思います。
・可逆性があるのであれば、根本的に暗号化は無意味
・検索しにくくなる
この２番目の検索しにくくなるのはそうですね。
利便性は損ねるかもしれません。
（データベース側で暗号化する機能を使った場合はそうとも言い切れませんが）
１番目の方はまた後で。
その暗号化の意図と詳細も教えていただけると幸いです。
基本的にはリスク回避が目的です。
悪意ある行為またはミスによって、データベースの内容がすべて露出してしまった場合そのままで使えなければ安全・・・いや、安全ではないのですが、まだマシです。
（一方で実行中のアプリケーションで復号されたものがバシバシ流出するとしたら、そこに対しては意味はないでしょうね。）
たとえば以下は今簡単に暗号化したものですが、
64 C4 D9 3B 1D 8F 0B 5B 26 0D 63 D4 87 EA 83 1A B9 92 A3 96 99 ED F4 5B 18 D8 CC 10 18 65 B9 09
これを元に戻せますか？
・可逆性があるのであれば、根本的に暗号化は無意味
についてですが、これは「容易に可逆可能なら無意味」ではありますが、根本的には無意味とまではならないと思います。
暗号化されたバイト列を復号するには鍵が必要です。
この鍵の管理がずさんなら（データと共に鍵と暗号化方式またはデータを利用するプログラムのソースなどまでバレれば）、容易に可逆可能なので無意味と言えます。
先ほどの暗号化はAES暗号(CBC)を使っています。
キーとブロックは128bitです。
鍵は "teraTail" です。
そこまでわかれば暗号化した内容はたしかにほとんど意味はないでしょう。
パスワードなど一部のデータに関しては可逆である必要は必ずしもないので不可逆な暗号化にしておいても構いません。
（暗号化して同じ文字列になるかどうかで正しいか判断できるからです）
また、暗号化は「現実的な時間では解けない」という理屈の上で成り立っていて、絶対ではない点も留意しておいてください。
投稿2016/08/09 10:46
総合スコア2604
> どのデータを暗号化すべきか（どこまで暗号化すべきか）というのはケースバイケース
ご経験された中で、どのようなケースがあったか、開示いただくことは可能でしょうか？
私個人のDBの利用方法の一つに、DB情報を元にした統計確認（たとえば、ユーザ属性の調査等）があるのですが、暗号化してしまうとそういった統計を取ることは難しくなると考えています。
多分、ケースバイケースとおっしゃっているので、複数回の経験があるのだと思いますが、
どのような発想で、そのデータの暗号化に踏み切ったのか
→その情報に対しての利便性を損なう判断の根拠は何か？
が、分かるような例があれば教えていただけないでしょうか？
仕事の情報を開示することはできません。
個人で作る場合はパスワードは少なくとも気を付けるでしょうね。
利便性に関しては、調査もそうでしょうがパッと見て元の値がわからない分、元の値を知りたいケースでは復号しないといけないというだけですね。
DB情報を基にした統計確認であっても、データの利用が許諾されていれば復号なりの手順を踏めば統計はとれると思いますが、なぜ難しいのでしょう（不可逆だデータに紐づく調査なら無理でしょうが）。「復号しなければならない」のが難しい理由であれば、それが利便性の問題です。
どのような発想かは回答に書いてありますが「悪意ある行為またはミスによって、データベースの内容がすべて露出してしまった場合」のリスク回避です。
> 仕事の情報を開示することはできません。
了解です。
> 「復号しなければならない」のが難しい理由であれば、それが利便性の問題です。
ここの理解が足りなかったようです。
統計を取る際に、復号し、その後削除でもすれば実現できるということですね。
理解しました。
かなり暗号化に対しての感触が変わりました！ありがとうございます。
0
金融検査マニュアルに、こんな記述があります:
- 金融機関が責任を負うべき顧客の重要情報を網羅的に洗い出し、把握、管理しているか。
- 洗い出した顧客の重要情報について、重要度判定やリスク評価を実施しているか。また、それぞれの重要度やリスクに応じ、以下のような情報管理ルールを策定しているか。
- 機密情報について、暗号化やマスキング等の管理ルールを定めているか。また、暗号化プログラム、暗号鍵、暗号化プログラムの設計書等の管理に関するルールを定めているか。なお、「機密情報」とは、暗証番号、パスワード、クレジットカード情報等、顧客に損失が発生する可能性のある情報をいう。
FISC 安全対策基準・解説書 には、こんな記述があります:
データ保護/漏洩防止/技28 蓄積データの漏洩防止策を講ずること。
これらに準拠するために、また監査で指摘されないために、顧客情報や機密情報は暗号化しています。
対象によってケースバイケースですが、OracleDBの透過的データ暗号化を使ったり、ネットワーク暗号化ツールを使ったり、電子政府推奨暗号リストを参考に、sha-2のようなトラップドア関数をかけたりします。
暗号化したまま検索が可能な秘匿検索技術 なるものがあるそうです。使ったことはないですが、興味があります。
投稿2016/08/09 10:52
編集2016/08/09 10:58総合スコア2493
暗号化したまま検索が可能な秘匿検索技術なんてあるんですね！
知りませんでした。
逆に、この技術を使用しない場合は、暗号化したままのデータをどのように検索するのでしょうか？oracle君だとなんか自動でやってくれるっぽいことが書いてあるのですが、よく理解できませんでした。
Oracle君がどうやってるのかは把握していません。アプリケーションはそのまま、設定ONにするだけです。そういえば、暗号化カラムを検索キーにしたことはないですね……そういう要件は当たったことないです。トラップドア関数を使うパターンのほうは、まあよくあるやりかたかと。
> 暗号化カラムを検索キーにしたことはないですね
そういう設計にしているんですかね。
その辺のノウハウに私が理解できていないものがありそうです。
> トラップドア関数を使うパターンのほう
これって、暗号化は易しくて複合は難しい関数と認識していますが、私の理解はずれていませんよね？これをつかった検索がよくあるやり方と読めたのですが、よくあるやり方というのが理解できませんでした。概要かキーワードを教えていただけないでしょうか？
ああ、ちょっと違います、トラップドア関数は単なる一方向ハッシュやダイジェスト関数であって復号しないまま使います。パスワードなどを照合するとき、オリジナルをもとに変換した値を保持しておき、入力されたものを変換した値がそれと一致すればOKとするものです。Linuxのログイン認証とか、Apache httpd のAuthモジュールとかで使っていたはず。
一致したかどうかはわかりますが、大小比較などはできません。
間違った理解だったんですね。恥ずかしい＾＾；
コメントいただいた内容は理解できました。
ありがとうございました。
0
社内の人給システムをマイナンバー対応にするときに暗号化の話がありました…。マイナンバーが平文でディスク上に存在してはならないみたいな要件があって、まぁ、対応のために購入するシステム(内製化なんて無理っすよ)は暗号化にもちろん対応しているんですけど、それをバックアップするときはどうするのかとか考えるのが面倒でした…。
さて、暗号化する理由は**「物理的な盗難」にあったときに備えるためというただ一点です。秘密鍵は地理的に別の場所にあることは当たり前の話**なので、ここでは議論しません。「論理的な盗難」は、プログラマーやSEが頑張れば、なんとかなる物です。セキュリティパッチを当てるとか脆弱性を防ぐ仕組みを随所に入れるとか、色々できます。ですが、どんなに強固なシステムであろうとも、盗んで、HDDを直接読んじゃえば、あってないような物です。
うちのサーバは○○社(好きな企業名を入れてください)のデータセンターにあるから…って言ってもやろうと思えばいくらでもできます。データセンターに入ったことがある人はわかるかと思いますが、結構簡単に入れます。中に入らないと作業できないから当たり前なんですけど、結局、性善説で入室を許可してしまいます。
A社のデータを盗もうとしたB社は、A社が利用しているデータセンターを把握し、A社のサーバと同じフロアにあるサーバを所有するC社を買収。A社から出向中のC社の関係者として、C社のサーバのメンテナンスだと申請し、堂々と玄関からデータセンターに入り、A社のサーバがあるフロアに侵入する。
なんて、産業スパイ映画(というより企業戦士Y○M○Z○KIにありそうって、古っ！)みたいなこともできないことは無いのです(もちろん、監視カメラやラックの鍵とかあるので、同じフロアに入れたからと言って簡単に盗めるというわけではありませんが)。専用フロアにすればいいって？どれだけ金が必要になるでしょうかね〜〜。うちなんて流行りのクラウドのA○Sだから大丈夫…いやいや、なんで外国のどこかにあるデータセンターがなぜ安全だと思うんですかね？クラウドなんて、物理的に一番信頼できないところです。それに、どんなに頑丈であっても、未曾有の天災で建屋が崩壊し、HDDが散らばっていた…なんてことが起きない保証は誰がしてくれるんでしょうか？(もちろん、一定以上の天災の場合の免責事項はちゃーんと契約書に書いてありますよ、責任は取れないって)
結局、どんなに金を掛けても物理を完全に防ぐ方法はありません。だからこそ、盗まれても大丈夫という仕組みを導入する事は意味があるのだと思います。
投稿2016/08/09 13:26
総合スコア21735
物理盗難ですか。その観点はなかったです。バックアップも対象になることを考えると、確かに危険だわ。。。
余談ですが、クラウドは営業にファシリティのFISC対応状況を聞くとある程度安心できますよ。某社で金融機関相手に販売していましたが、結構ちゃんとしていました！多分、その手の資料をちゃんと出す会社はちゃんとしてますｗ
横から失礼いたします。
HDD暗号化などについては確かに物理的な防御の主とは思うのですが、それだけのみと断言はできないと思います。
暗号化にはこちらの対策時間を確保するための時間稼ぎ的な役割もあると考えてます。
例えば攻撃者にネットワーク内に潜入された場合、暗号化のされていないデータをすぐに盗聴されるリスクがあります。
その点、何重にも防御を張っておけば潜入されて即致命的な被害となるケースを予防できるのかなと思ってます(暗号化も防御手段の一つ)。
> te2jiさん
どこも運営はしっかりしてますよ。データセンター内にあるHDDが盗まれる可能性なんてほとんど0%でしょう。でも完全に0%ではありません。それをどう考えるかだけです。どんなことがあっても100%保証してくれますか？と言って首を縦に振るような企業があれば、私は逆に信頼できません。
> KotoriMaturiさん
データベースの暗号化の話であり、通信の暗号化ではありません。流れるパケットを眺めているだけの盗聴では、どうやってもデータベース上のデータを直接盗むことはできません。盗むにはサーバ自体に侵入する必要があります。侵入に成功している時点で、root権限が取られている可能性が高いです。root権限があればメモリ上の秘密鍵も取り放題なので、暗号化など有名無実です。
> raccyさん
質問テーマを超えて、データベース暗号化以外と交えてしまってたので、明後日なこと言ってました、失礼しました^^;
> raccy さん
クラウド販売してた時に散々言われた内容に触れられたのでコメントしちゃいました。
ここを見た人用に参考リンク貼っておきます。（競合でしたがｗ）
https://d0.awsstatic.com/whitepapers/jp/security/FISC_Document_20120824JP.pdf
0
クレジット・カードの番号は漏えいすると致命的なことはご理解いただけますよね。詳細なテーブル定義情報、実際に実行されるSQLもまねされたくないなど、公開したくない場合もあります。
投稿2016/08/09 10:04
総合スコア16415
そのような実例をご経験されているという認識で正しいでしょうか？
経験しないで済むようにあらかじめ対処しておくんです。
安心してインターネットを使うために
http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/index.html
など初歩的な情報からご覧になっては？
誤解される書き方でしたね。失礼。
そのような構築をされた実例をご経験されているという認識で正しいでしょうか？
また、
> 詳細なテーブル定義情報、実際に実行されるSQLもまねされたくない
こちらのコメントに関して、理解できませんでした。
SQLに関して、ある実行結果を求めようとすると、幾つかの方法があるにしても、似通ったものになると思いますが、そうならないための仕組みを導入するということですか？
> http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/index.html
一通り読んだんですが、どこをご紹介されたかったのか理解できませんでした。
セキュアマトリクスもどきの図があったりして楽しめはしたのですが。。。
0
個人的には、情報自体を暗号化するのはちがうんじゃないかな、と。
やるとしたらシステムへの出し入れをセキュリティ的に固める方向で。
システム的には強固であっても、ソーシャルハッキングに対しては
ガバガバだってことはありがちですよね。
そのへんをどうバランスとって納得していくかじゃないのかなあ。
投稿2016/08/09 10:13
総合スコア7458
今までのご経験上は、DB登録する情報を暗号化するケースはなかったということでしょうか？
社内システムばっかだったんで、そのへんは無いスね。
話はそれますが、実際の顧客データを使ってテストする際に
暗号化(というか意味のない文字列化)してたことならあります。
この場合は帳票出力が主なテスト内容だったので可能な話です。
あ、ちなみにPHPとかやってたとことは別のとこのはなしです。
社内システムだから、ソーシャルハッキングを優先的に気にされていたんですね。
それはそれで面白い。
ご回答、ありがとうございます！
0
おっしゃる通り、可逆性のある暗号化では読み取ることが可能ではありますが、それでも無駄ではないかと思います。
例えば顧客情報を含むデータレコードであったとして、
データベースをごっそり抜き取られるようなケースを想定した場合、
そのままで顧客情報を読み取ることができてしまいます。
しかし暗号化されている場合、可逆化解読技術がない場合は、読み取られません。
それだけでも、情報流出を抑える意味があると思います。
（例えば可逆化に暗号キーが必要な場合であれば、さらに解読に手間がかかります）
完全ではないかもしれませんが、大事なお客様のデータを守るために、できることをできる限り行うことは無意味でないと思います。
投稿2016/08/09 10:02
編集2016/08/09 10:28
総合スコア440
考え方は理解しているつもりなのですが、実例としてそのような設計をするケースがあるのか知りたくて、質問しました。
ご経験上、データを暗号化するようなケースがあれば、できれば内容とともに教えていただけると嬉しいです。
例えば、顧客情報等です。
いわゆる個人情報を暗号化したということですね。
非常に興味深いです。
その場合、検索がかなり困難になるのではないかと予想しますが、特別な仕掛けをされたということでしょうか？
検索は非常に困難になりますが、できなくはありません。（具体的な方法は本主旨と異なるため割愛いたします）また、検索の仕様（一部一致ＯＫ or 全一致など）クライアント様の意向にもよるかと思います。（利便性重視方向、セキュリティ性重視方向など）
> 具体的な方法は割愛いたします
まぁ、そうですよね＾＾；
クライアントの仕様により個人情報に暗号化を行い、かつ検索要件も仕様としてあるケースを経験されたということで、理解しました。
回答で phpmyadmin に触れられていますが、こちらのケースでも使用されていたのでしょうか？
恐れ入りますが、本質問内容の主題とずれておりますので、ご遠慮願えれば幸いです。
わかりました。興味深い回答をありがとうございました！
0
では今とあるサイトでやっている事実だけを
クレジットカードや口座番号など本当にばれちゃいけないデータは外部サービスに保持してもらいそこからの電文を利用して処理しています。
まあその外部サービスが流出したらどうすんだという問題はありますが、自社でそういう情報を持っておくより安全です
個人の登録情報で暗号化する内容はパスワードだけ行っています。
投稿2016/08/09 10:45
総合スコア1820
回答ありがとうございます。
電文利用ということは、ネットワークの暗号化ですね？
DB内の情報暗号化もされているのでしょうか？
外部サービスの選定時にDBの暗号化等も指標の一つになったのではないかと思いますが、もし差支えなければ、暗号化した情報が何で、どのような判断からか教えていただけると幸いです。
すいませんが、私はそういう地位におらず外部サービスは営業と顧客で決めたのでなぜそうしたのかは不明です
暗号化は特に行っていません。そのサービスの電文がわからないとただの数字にしかみえないですが
外部サービス利用による、責任分界点の転嫁対応というのも、秘匿データに対して一定の需要があるということですね。
コメントありがとうございました。
0
私の場合は、小規模システムが多いので、データベースの暗号化という要件があまりないのですが、提案することもあまりないですね。しいて言えばパスワードのハッシュ化ぐらいなものです。
使い勝手やパフォーマンスの面でデメリットが大きいのは指摘の通りだと思います。
検索しにくくなるというのが最大の問題点だと思います。
物理盗難についての問題もありますが、これについてはファイルシステム自体を暗号化したりなど、別のレイヤで行ったほうがメリットが大きいように思います。
投稿2016/08/09 13:58
総合スコア1939
暗号化を別レイヤで行う場合も結局パフォーマンスとの兼ね合いになるようなので、要件次第っぽいですね。
あまり詳しくないので、今調べ始めたところですが＾＾；
あなたの回答
tips
プレビュー
