  |
はてなキーワード: SSL証明書とは
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
★★再追記
レンタルサーバは、自由度が低くてストレスになるからやらない。SQLでwith使いたいからMySQL8をって言ってもさくらレンタルサーバじゃ無理なんでしょ？ あと同居利用者のせいで高負荷ってのも避けたい。そこを気にしない人はレンタルサーバでいいと思うよ。
あと LB $0.025/h だった。月2000円くらいか。
★追記
LBは独自ドメイン+自動更新無料SSL証明書のためね。Cloud Storageの無味乾燥なドメインでいいなら、SSL自動かつ無料でほんとに月数円。
－－－－－－－
もうねめんどくさいんだわ。もちろん以前はそうやってたよ。
PHPだのApacheだのMySQLだのインストールしたり設定ファイル置いたり、
脆弱性対応したり、SSL証明書更新したり、一応落ちてないか無料監視サービス使ったり。
でも仕事ならともかく、趣味だからこそこんなことやりたくないじゃん。
なので、コンテンツは Cloud Storage に置く。
Cloud Load Balancing も使う (無料 SSL 証明書のために)。
動的部分は Cloud Functions で。
AWS なら S3+ALB+Cognito+Lambda だな。
そうしておけば、放置できる。自前で立てたマシンもインスタンスもないから落ちてるかどうかとか気にしなくてもいい。負荷も考えない。クラウド様がよきにはからってくれるさ。たまにクラウド障害あるかもしれないけど、Google なり AWS なりが頑張って直してくれる。
って感じ。
ちなみにこちらは 1日数十アクセスの過疎サイト。独自ドメイン+自動SSL証明書にするための Cloud Load Balancing に 4000円くらい払ってる。それがなければ月数円。
表記の件について意見募集が開始された (https://www.digital.go.jp/posts/ckWVVAya) というので仕様(https://cio.go.jp/sites/default/files/uploads/documents/digital/20210917_spec_01.pdf)を見たら、なんか国のお墨付きの個人情報の名簿登録補助ツールみたいな上に、証明書としては全然機能不足にしか見えず、がっかりした。
批判だけでもなんなので、自分ならこういうの作るという意見書出しといた。
などの理由から、有益とは思えないし、電子証明書としての信憑性も非常に疑わしいシステムしかできないように思われる。
この仕組みを活用したい立場としては、「接種者の個人情報」ではなく、「二次元コードを提示した人が接種済みであること」が確認できればよいので、
2. 申請した個人（ないし端末）毎に、APIサーバでユニークなIDを発行する
3. システムの接種確認用APIに2.のIDを付けたURLをQRコードで表示する（IDを種として、ワンタイム識別子をアプリとサーバで計算するなどの設計も考えられる）
4. APIにアクセスすると、接種証明情報として、最終接種回数と接種日のみを返す
2. QRコードのURLが偽サイトではないことを検証する（HTTPSのSSL証明書確認ぐらいでも十分で、政府が発行する公式アプリとすることで信憑性を担保する）
もっと踏み込むと、国として、接種証明として表示した国民の個人情報が、民間企業において確度の非常に高い顧客名簿になりかねない、という点については、どのように考えているのかはなはだ不安を感じさせる仕様と言わざるを得ない。
（ここまで）
いま読み返していて単純に「IDを種」にするだけではダメなことに気づいた。申請時にワンタイムトークン計算用の秘密の種を共有しておいて、個人（端末）の識別用IDとワンタイムトークンをAPIに渡すようにする、とかが必要だった。
国民の個人情報を、わざわざマイナンバーカード使って本人性を保証した上で自動読み取り可能な形でスマホの画面に表示するだけのアプリって、どこぞのeKYCの対極ネタとしては面白い（面白くない）。
4台のPCに一つずつ稼働させることにした。
【よかったこと】
・IISというWindowsのサーバー建てるフレームワークみたいのを使って初めてWindowsでサーバーを建てる経験を得られた。
Windowsでサーバーを立てるのは規約違反だった気がしたが最近はWindowsに元々サーバーを建てる機能が付属してるし別にいいのだろう。
・Windows10のドライバ認識能力のすごさを知ることができた。
Linuxだとファンが回らない、何も映らないけどWindowsだと普通に動くなどした。
・Windowsでサーバーを建てるのはムズイという知見を得た。
・信じられないくらい遅い
CPU使用率が低いままで全く変わらず、にもかかわらず簡単なウェブページの表示に10秒とか待たされて使い物にならなかった。Xubuntuに変えたら1秒以内に表示された。
httpsにリダイレクトされるのをやめさせようとしたり、SSL証明書を設定しようとしたがどうやってもできなくてWindowsを使うこと自体を辞めた。
・家に余ってたHDDを全部繋げて1.5TBのクラウドサーバーを作ることができた。
複数のHDDを一つのHDDとして扱う技術（LVM）の設定をする体験ができた。1.5TBの使い道はない。不用品の処分をするのが目的。
・XubuntuならMacbookPro(2007年製)にUSBメモリからインストールできることを知った。ただしインストール画面がたまにしか表示されない。
【デメリット】
・今までは仮想マシンで動かしていたので扱いやすかったのだがそれができなくなった。
失敗しても5分前の状態に戻すとかできないし、仮想イメージのエクスポートとかできない。
・電気代を4倍食うようになった。
別に珍しくもない話じゃないかと思うけど、最近もなんかあったの？
オレオレ詐欺的なヤツはソーシャルハックだからオンライン化するしないってのは関係ないけど
公式でオンライン化しちゃうと区別のつきにくい模倣ってのはどうしても取り締まりきれないよね。
最近はGoogle様も「お前らどうせSSL証明書の内容なんかそんなに見ねーだろ？」って表示を分かりづらくさせる方向だし
独自エンジンのブラウザってFirefoxしかねぇけどアンチ広告な姿勢のせいで企業のサポートどんどん得られにくくなるだろうし
以前は信頼できなかった。
使い勝手も悪かった。
利用していない遠方の金融機関で
「「最新バージョンで利用して下さい」のような警告が出たら、
OK も キャンセル も押さずに 右上の Xボタン をクリックして下さい」
と案内があると(警告無視推奨)、
急場しのぎには仕方ないのだろうが、1年以上対応そのまま。
ワンタイムパスワードや2段階認証など、
以前の体験や見聞により、金融機関のネット利用手続きには不安が大きい。
令和 2020 年代に入り、悪い病も流行し、ネットで済むなら利用したい。
しかし怖い。
信頼できないシステムを使いたくない。
https://anond.hatelabo.jp/20200417230216
弊社の新規事業でWebサービスを作っていて、セキュリティトレンドの常時SSLってやつをやってみようと思った。
世のWebサービスを見てみるとやっている所が何故かほとんどなく、mixiやニコニコなどの大手もやってないようだ。ニコニコのURLを試しにhttpsにしてみたら繋がらず、mixiはhttpにリダイレクトされる。
うちは新規だから最初からhttps化することで特にデメリットはないと判断、安いSSL証明書を買ってhttpをhttpsにリダイレクトするようにした。技術的な難所はまったくないので問題なく実装完了し、これで安心度がちょっと上がったと思っていたのだが…。
つづく。
続き。
弊サービスではユーザーがYouTubeなどの動画を貼り付ける機能が重要なのだが、テストしてみるとニコニコ動画の埋め込みが動作しなくなっていた。調べてみるとニコ動の埋め込みコードがhttpなせいで、さらに最近のブラウザはhttpsページの中にhttpコンテンツがあると、警告も出さずまったく表示しない仕様になっているようだ。
何か解決方法はないかと調べてみると逆に、同じ理由でhttps未対応の広告やアフィリエイトも貼れないことが判明。広告モデルの無料サービスなのでこれは致命的。
というわけで当初の予定とはまったく反対の、httpsをhttpにリダイレクトする羽目になるという笑えるオチになってしまった（httpsで見られると広告なくなっちゃうため）。それでmixiもニコニコも対応してなかったのか…。
http://webbingstudio.com/weblog/cms/entry-773.html
小規模の商用サイトでは、フォームを暗号化する際には、共有SSLを利用するのが当たり前となっています。独自ドメインのSSL証明書を取得すると、フォームを通して得られる収益よりも、維持費の方がはるかに高くなってしまうからです。
とこの記事では書かれていますが、一体どこで「当たり前」なんでしょうか？
SSL証明書の取得費用は、サーバーホスティングによって額がまちまちなのは確かですけれども、
安く独自SSL証明書を取得して利用できるサーバーホスティングは山ほどあります。
WEB制作者として「自分が良く知っているだけ」のサーバーのレンタルをクライアントに押し付けてはいませんか？
また、小規模商用サイトにしても、仮に年額35,000円のSSL証明書をつけ、かつ、月額3,000円のサーバーを借りていたとすると
月額でいえば6,000円くらいの負担ですが、
いくら小規模とはいえ、広報活動の中核をなすWEBサイトであるならば、
月額6,000円をペイできないとすると、
（というか、効果測定をしていないだけ？）
共用SSLのリスクに関して言えば、この記事が引用している、高木浩光氏の書かれている通りではあります。
cookieが取得できてしまう結果として、一番最初に狙われるのは、管理画面へのログイン。
いわゆるセッションハイジャックです。
ログイン状態を乗っ取られた時点で、どんなCMSでも、WEBサイトの改ざんは可能です。
なぜか。
そのコンテンツは多くの場合MySQLに代表されるDBに保存してあります。
したがって、ファイルの改ざんなどを行わずとも、WEBサイトの内容は書き換えることが可能なのです。
「なるほど」と思ってしまうかもしれないので、
早々に訂正していただきたい。
また、この記事にある a-blog cmsというCMSについてはよく知りませんが、
多くのモダンなCMSでは、ほとんどの管理画面ログインにおいて、
セッションハイジャックに対する防衛は行われていますので、
cookieの取得が、即WEBページの改ざんに繋がるような書き方も、
ここも早々に訂正していただきたい。
この筆者さんは、a-blog cmsというCMSを利用されているようだ。
このCMSはどうやら、PHP製ながらPHPのソースを暗号化しているようだ。
こう言ってはなんですが、攻撃者にしてみれば、a-blog cmsを攻略するくらいならMovable TypeやWordPressを攻めた方が楽というものです。
この記述はむちゃくちゃである。攻撃者にしてみれば、誰でも手に入れられるCMSであれば、
a-blog cmsの公式サイトを拝見すると、MySQLを利用しているようで、
ファイルの暗号化はなされていようとも、DBの中身の仕様は丸見えだ。
前提条件として「知っている」「知らない」の差はあれど、攻撃に関して「ラク」というのは
どう考えても楽観的に過ぎる考えだ。
どうも「SSLで確保される安全の領域」について、かなり認識が甘いようだ。
SSLはあくまで、TCP/IPネットワークにおいて通信経路を暗号化するための技術だ。
通信する際に、通信先のサーバーが正しく認証されているかどうか？に必要なのはSSL証明書。
で、ここに書いたとおり、SSLはあくまでサーバーと利用者の通信においての暗号化だ。
この記事に書かれていることは「メールフォームについて」のことのようだが、
サーバーに到達したあとのメールについては安全性をかんがえていますか？
メールは全く暗号化されず平文で送信されるとても脆弱な通信手段だ。
いくらSSLで通信を暗号化しようとも、問い合わせフォームの送信がメールだったとすると…
とこの記事ではかかれていますが、そもそもHTTPやHTTPSの通信を傍受するより遥かに
メールを傍受したほうがラクとも考えられるはず。
CMSの機能に甘んじて、こういったベーシックな問題に考えが及んでいないとすると、
とおもう。
記事に対するつっこみではないですが、
正しくは「TLS」でっせ。
去年の今頃は「今年こそはすごいWebサービス作るぞ！！！！！！！！！！！」って意気込んでたのに
なんかもう今日が最終日。
ということでこの12月頭から何か作ろうと考えていて、丁度年末だからということで作った。
前にAmazonの購入金額合計を出すブックマークレットが流行ったけど、それとほぼ同じ。
Amazonの今までの合計金額と、書籍とかPCとかカテゴリごとの合計金額出してグラフにする。
年末だしTwitterで「2014年のKindle購入金額内訳は...でした」とか投稿すれば
みんなつられてアクセスするはず！宣伝しなくても勝手に大ブーム間違いなし！！！！！！！！
って思ってたけど
投稿してもだれもアクセスしてくれない。待っても待ってもアクセス0。
e？嘘でしょ？？？って思ったら
のはずだったけど今度はrobots.txt見に来るクソbotしかアクセスしてくれない。
虚しさ半端ない。
というかTwitterでURLつぶやくと即効でどこぞやのクローラー巡回してくるんですね。
構成自体はクライアント・サーバサイド共にjs。EC2上でnode.js。
D3.jsのグラフ画像がsvgだからどうにかしてpngにしないとTwitter投稿出来ないのが微妙に面倒だった
投稿時にクライアント側でbase64→canvas→pngにしても良かったけど
商品のカテゴリ取得するためにはProduct Advertising API使うしかなくて
redis上にキャッシュしておいたりwebsocketで適当に進捗伝えたりした。
今回得た経験値としては
あたり。
今年は残念ながら目標不達成だったけど、いい最終日の過ごし方になったと思う。
お疲れ様でした。
MUFJのオンラインバンキングを申し込んでみたのだがそこでセキュリティーソフトを推奨された。
こいつだ。http://www.trusteer.com/ja/products/trusteer-rapport-for-online-banking-ja
残難ながらこれのダウンロードリンクはhttpsでは提供されていない。賢明な諸兄はご存知の通りhttpsで提供されていないソフトは信頼しないことが大原則だ。
ファイルがhttpsで提供されない場合はhttpsで提供されているMD5情報などを元にファイルの正当性を確認する必要がある。
何と言っても、オンラインバンキング専用セキュリティーソフトだ。最大限の注意を払う必要がある。
さて、困惑した私は会社のサポートチャットに問い合わせをすることにした。
"httpsで提供されていないソフトウェアをどうやって信頼すればいいのでしょうか？"というのが、はじめの質問である。
以下がそのログの抜粋（担当者のフルネームが表示されていた箇所を「サポート」と伏せている）
サポート: httpsで提供されていないソフトは、インストールの際にソフトウェアのデジタル署名をご確認ください。
増田: Trusteerエンドポイント保護のアンインストール.appを実行する場合はインターネットからダウンロードしたソフトですが信頼しますか？というようなことが表示されますよ。
サポート: はい。アップルストアからの提供品ではないためそのようなメッセージが表示されることもございます。
増田: また、OS Xでは署名はappleが認証したデベロッパーが開発したソフトウェアであることをを証明してもデフォルトでは提供元を表示する機能は無かった様に記憶してますが
サポート: ルート証明が正しければ正しい提供元としてTrusteerが表示されますので、ご確認いただけますでしょうか。
増田: えーと、それはどのようにすればいいのでしょうか？
サポート: 申し訳ございませんが、この内容はRapportのサポート範囲外となりますので、お答えできかねます。インターネット等でお調べいただけますでしょうか。
サポート: 正規のソフトウェアである事をご確認いただくための情報としては、組織に「Trusteer LTD」が表示されていることとなります。
増田: ではもう一点
増田: httpsで接続先が偽物というのはどのような場合でしょうか？ 考えられるのは 1.接続先の秘密鍵が漏れている場合 2.接続もと(ブラウザなど)が信頼できない認証局を信頼している 3.サイトがハックされている などのケースが考えられますがどのようなケースを想定していますか？
サポート: サイト自体がハッキングもしくは、ファーミングされたケースを想定しております。
サポート: ファーミングされた場合、偽者のSSL証明書を利用することでhttps接続となりますが、接続先は偽者、となります。
増田: 私がrapport.pkgをinstallしようとする際にはpasswordを求められるまでの間にアプリケーション提供元や署名の表示などは行われませんでしたが、これは問題ないとお考えですか？
増田: おそらくwindowsだと提供もと証明などがでてくるのでしょうけど。
サポート: 署名の表示は、お客様の操作によって表示されるものですので、Macの仕様となります。
増田: なるほど、比較的容易な攻撃方法であるDNSポイゾニングなどで間違った接続先に接続した場合、OSXユーザーは能動的に確認する以外に自衛手段はないということでよろしいでしょうか？
サポート: はい。Rapportを導入していない状況ですので、お客様ご自身の自衛手段となります。
サポート: 予定につきましてはお応え出来かねますが、ご要望として担当部署に伝えることは可能でございます。
増田: OSXユーザーがRapportインストーする際にそのような自衛手段を案内することはRapportのサポート範囲外ですか？
サポート: 申し訳ございませんが、そうなります。ただデジタル署名の情報でしたら先ほどご案内した通りでございますので、デジタル署名をご確認ください。
サポート: また、デジタル署名をご確認いただくことで、ソフトウェア自体に改竄が加えられていないこともご確認いただけますので、http/httpsに関わらず確かな方法となります。
増田: その確認方法は自分で調べないといけないということですか？
サポート: 申し訳ございませんが、ご自身でお調べしていただくようお願い申し上げます。
増田: わかりました、ありがとうございます。 予算さえあれば私でも御社のセキュリティーソフトの偽物を容易に配布できることをよく理解しました。
サポート: お客様への回答は以上となりますが、他に何かご不明な点などはございますでしょうか。
増田: いえ、ありがとうございます。
